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Prefata 


Misiunea cartii de fata este, cel putin pentru autori, atat una relativ dificila, cat — mai 
ales! — atrágátoare: ne propunem să prezentăm sistematic unul dintre domeniile 
importante, dinamice si de succes ale tehnologiilor actuale — serviciile Web. Astfel, 
adresam acest volum viitorului sau actualului programator Web care dorește să se 
iniţieze în tehnologiile și metodologiile de dezvoltare a serviciilor Web bazate pre- 
ponderent pe SOAP. Desigur, nu uităm nici abordarea REST, concretizată în ilustrarea 
invocarii de servicii în mod asincron via suita de tehnologii AJAX. 

Plecând de la metafora că putem asemăna un serviciu Web cu o portocală, vom 
încerca să „decojim” straturile — poate uneori mai aspre — ale specificaţiilor privitoare 
la descrierea prin WSDL a interfeței și implementării serviciului, la protocolul de 
transport SOAP si la descoperirea prin diverse metode (¢g., UDDI) a serviciilor 
disponibile în regim public sau privat. Într-un anumit moment vom ajunge și la miez, 
adică tocmai la prezentarea limbajelor, instrumentelor si platformelor ce oferă suport 
pentru crearea și invocarea de servicii Web. 

Programatorii se vor putea delecta cu diverse biblioteci, framework-uri si servere de 
aplicaţii, prinzând gustul implementării de servicii (cu mult) mai complexe. Nu uităm să 
enumerám noţiunile de bază privitoare la familia XML — baza pe care se fundamentează 
întreg, eșafodajul de limbaje si initiative privitoare la serviciile Web — ori să „tragem cu 
ochiul” la livada de portocali actuali, (reprezentând perspectivele domeniului. 

Materialul îi are drept destinatari pe toti cei interesaţi de tehnologiile Web în general 
si de servicii Web in special: studenţi de la facultăţi de profil, elevi din clasele terminale, 
dezvoltatori din cadrul companiilor, alte categorii de specialiști în informatică sau în 
domenii conexe. Notám, en passant, cá una dintre cerinţele obligatorii ale secțiunii 
Software Design a deja bine-cunoscutei competiţii internationale Imagine Cup este ca 
fiecare echipă concurentă să implementeze cel putin un serviciu Web... 

Vom descrie în continuare structura lucrării de fata. 

Capitolul 1 conţine o prezentare generală a serviciilor Web, în contextul dezvoltării 
aplicaţiilor distribuite bazate pe XML. Tot aici realizăm o trecere in revista a carac- 
teristicilor principale ale protocolului HTTP, introducem SOA (arhitectura orientată 
spre servicii) si discutăm necesitatea existenţei tehnologiilor SOAP, WSDL, UDDI, 
REST. 

Al doilea capitol se focalizează asupra familiei de limbaje XML. Descriem sintaxa, 
spaţiile de nume, manierele de validare și tehnicile de procesare a documentelor XML. 
Insistăm asupra unor concepte privitoare la XML Schema și modelul DOM, deoarece 
ne vor fi de folos pe parcursul cărţii. 
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Cel de-al treilea capitol este dedicat manierei de descriere a serviciilor Web. În 
primul rand, ne oprim asupra limbajului WSDL: componente, tipuri de documente, de 
operații si de mesaje, exemple si instrumente de lucru. 

În cadrul capitolului patru detaliem „inima” serviciilor Web — SOAP. După o 
succintă prezentare a protocoalelor de transport bazate pe XML, realizăm o privire de 
ansamblu a protocolului SOAP. De asemenea, printre altele, sunt descrise: structura si 
maniera de codificare a mesajelor, modul de procesare si transport ale datelor, relaţia 
dintre SOAP si HTTP si diferenţele dintre versiunile în vigoare ale acestui important 
protocol. 

Capitolul cinci are drept subiect descoperirea serviciilor Web. Prima parte se 
focalizează asupra UDDI, unul dintre cele mai populare mecanisme de căutare a 
serviciilor, mai ales prin prisma proceselor de afaceri pe care le modelează. După 
detalierea arhitecturii UDDI, a tipurilor de informaţii stocate si a intimitatilor privind 
funcţionarea, oferim și o soluţie practică de constituire a unui registru UDDI propriu 
prin intermediul instrumentului open source /UDDI. A doua parte a capitolului vizează 
descoperirea dinamică a serviciilor prin WS-Inspection. 

Pentru unii dintre cititorii mai grăbiţi, capitolul şase ar putea reprezenta cea mai 
incitantă parte a volumului, deoarece cuprinde ,,retete” de „sădire” a serviciilor Web — 
fie ele referitoare la portocale (albastre) sau la alte aspecte — și de „consumare” a 
functionalitatilor oferite de acestea. Am folosit majoritatea limbajelor de programare 
(C/C++, CH, Java, Perl, PHP, Visual Basic), a instrumentelor (Apache Axis2, gSOAP, 
NuSOAP, SOAP::Lite) şi mediilor de dezvoltare (NET, Java, Delphi) actuale, fie ele 
comerciale sau liber disponibile. Tot aici punctám etapele care trebuie parcurse pentru 
accesarea serviciilor Web externe (Google și XMethods) și ilustrăm principiile de bază 
ale suitei de tehnologii AJAX. Prezentám, de asemenea, maniera de invocare asincroná 
a serviciilor Web, fie direct — via programe JavaScript —, fie pe baza unor biblioteci si 
framework-ati precum Prototype şi Atlas ASP.NET. 

Ultimul capitol realizează o recapitulare a tematicilor atinse si trasează diverse 
direcţii de evoluţie, invitându-i pe cei interesaţi să aprofundeze domeniul. Astfel, 
prezentăm succint initiative industriale ca WS-Addressing, WS-Discovery, WS-Coordination 
sau WS-AtomicTransaction. Suplimentar, punem în discuţie aspecte referitoare la ingineria, 
securitatea și asigurarea inter-operabilitatii serviciilor Web. Spre final, „degustăm” rapid 
rolul serviciilor Web în cadrul proceselor de afaceri, al sistemelor de tip grid si al noului 
Web (ale cărui tendinţe sunt cunoscute sub denumirea generică de Web 2.0, etapă 
preliminară Web-ului semantic). 

Volumul se încheie cu un set cuprinzător de acronime folosite în text și, în mod 
firesc, cu o bibliografie generală. 

Această carte nu ar fi ajuns la forma actuală fără ajutorul oferit — atât prin 
parcurgerea versiunilor preliminare, cât si prin formularea unor sugestii utile — de 574 
Alboaie, Mihaela Brut, Diana Gorea, Adrian Iftene, Loredana şi Stefan Tanasa şi, nu în ultimul 
rând, Cosmin V'árlan. Suntem recunoscători profesorilor nostri Toader Jucan, Cornelius 
Croitoru, Dorel Lucanu şi Henri Luchian, de la Facultatea de Informatică a Universităţii 
„Alexandru loan Cuza” din laşi. De asemenea, mulțumim familiilor noastre si echipei 
de profesioniști a Editurii Polirom. 


PREFATA 11 


La finalul acestei prefețe trebuie să menţionăm contribuţiile autorilor, după cum 
urmează: capitolele 3, 4 si 5 au fost redactate în principal de Lenuta Alboaie, care a 
realizat si implementarea exemplelor de servicii Web scrise in limbajele C/C++, Java 
si Visual Basic .NET din cadrul capitolului 6. Restul materialului, inclusiv ilustratiile, a 
fost preponderent conceput de Sabin Buraga. 

Pentru experimentarea codului-sursa al programelor incluse, nu ezitaţi să vizitaţi 
adresa http://www. infoiasi.ro/ ~busaco/ books/ws/. De asemenea, vă invităm să ne contactaţi 
prin posta electronica la adria@infoiasi.ro și, respectiv, busaco@infoiasi.ro. 


Autorii 
lași, 3 septembrie 2006 


Capitolul 1 


Prezentare generală a serviciilor Web 


„Cea mai bună cale de a prezice viitorul 
este să-l inventam.” 


(Alan Key) 


1. Preambul 


Spaţiul World Wide Web reprezintă un sistem de distribuție locală sau globală a 
informațiilor hipermedia, văzut ca univers informational compus din elemente de 
interes, denumite resurse, desemnate de identificatori globali — URI (Uniform 
Resource Identifiers). 

Din punct de vedere tehnic, Web-ul pune la dispoziţie un sistem global si 
standardizat de comunicare multimedia (summum de media), informaţiile fiind 
organizate asociativ si distribuite in functie de cererile utilizatorilor, functionand 
conform modelului client/server. Prin definiție, cHentu/ (în cazul nostru denumit 
si navigator sau agent-utilizator Web) solicită servicii (informaţii) de la com- 
ponenta server. Serverul răspunde așadar cererilor clienţilor, protocolul folosit 
fiind, uzual, HTTP (HyperText Transfer Protocol). 


1.1. Protocolul HTTP pe scurt 


Data fiind importanta protocolului HTTP, vom realiza in continuare o trecere in 
revista a caracteristicilor sale importante. 

Protocolul HTTP, standardizat de documentul RFC 2616, este folosit in 
special pentru hipertext, dar poate fi considerat drept protocol generic, baza 
comunicării într-un sistem distribuit de management al datelor, în cazul WWW 
fiind vorba în principal de facilitarea transferului de date între clienţii și serverele 
Web. Fiind un protocol utilizat în Internet, HTTP se situează la nivelul de 
aplicaţii al stivei de protocoale TCP/IP (Transmission Control Protoco// Internet 
Protocol), putând fi considerat fiabil (re/zab/e). 
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Concepte fundamentale 


Conceptele de bază sunt cererea si răspunsul un client Web trimite un mesaj 
(cererea) la un server. Mesajul conţine identificatorul resursei dorite, dat sub 
forma unui URI (Uniform Resource Identifier), metoda de acces folosită, versiunea 
protocolului, precum și o serie de meta-informatii care pot fi utile serverului. 
Răspunsul serverului cuprinde un cod indicând starea serverului după inter- 
pretarea cererii, un mesaj explicativ pentru codul de stare transmis, meta- 
-informațiile care vor fi procesate de către client si, eventual, un conţinut (e.g., 
resursa solicitată). 

În general, o sesiune de comunicare HTTP este iniţiată de către client si 
constă din solicitarea unei resurse (o pagină Web, uzual) identificată unic pe un 
server cunoscut. Acesta este numit și server de origine datorită faptului că în 
comunicarea între client si server pot să apară unul sau mai multi intermediari: 
proxy (numit și server proxy), poartă (gateway) sau tunel (tunnel), Entitatea proxy 
reprezinta un intermediar care retrimite un mesaj HTTP, eventual modificand o 
parte a sa. Poarta semnifică un intermediar care se poate situa înaintea unui 
server de origine și să se identifice drept acesta, clientul Web necunoscând acest 
aspect. Tunelul este un intermediar care nu schimbă conţinutul mesajului, ci are 
rolul exclusiv de retransmitere a lui; de exemplu, tunelul poate fi folosit pentru 
(de)criptarea mesajelor vehiculate între server si client în cadrul unui intranet/ 
extranet. 

Un alt concept important este cel de cache, desemnând un depozit local de 
stocare (în memorie, pe disc) a mesajelor (datelor) la nivel de server/client. Un 
proxy deţine obligatoriu un cache, denumit si sistem de cache. 

Un exemplu tipic de cerere-raspuns este următorul, în care cererea — formulată 
de un browser — are forma: 

GET /catalog produse.html HTTP/1.1 

Host: www.portocale.info 

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; 

rv:1.8.0.5) Gecko/20060719 Firefox/1.5.0.5 

Accept: text/html, image/gif, image/jpeg, */* 

Accept-Language: en-us 

Accept-Encoding: gzip, deflate, compress, identity 

Connection: Keep-Alive 


Un posibil raspuns — obtinut din partea serverului Web — ar putea fi urmatorul 
(am omis continutul propriu-zis al documentului solicitat): 


Date: Tue, 22 Aug 2006 07:17:13 GMT 
Server: Apache/2.0.54 (Win32) PHP/5.0.4 
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Accept-Ranges: bytes 

Content-Length: 201 

Keep-Alive: timeout=15, max=74 

Connection: Keep-Alive 

Content-Type: text/html; charset=ISO-8859-1 


Adresarea resurselor via URI 


Modalitatea de adresare a resurselor Web este reprezentată de sdentificatorii uniformi 
de resurse — URI (Uniform Resource Identifiers). Mulțimea URI e compusă din 
localizatori uniformi de resurse — URL (Uniform Resource Locator) — şi nume uniforme 
de resurse — URN (Uniform Resource Name). 

Adresele de tip URL sunt folosite in localizarea unei resurse in retea (in 
special in Internet) prin protocolul HTTP, având forma bine-cunoscută 
http:/ / server:port/ cale?interogare, unde în mod implicit, dacă nu e precizat, portul se 
consideră 80, iar cale reprezintă un sir de directoare delimitate de ,,/”, terminat 
eventual cu numele fișierului care stochează resursa adresată prin intermediul 
URL-ului. Componenta /pferogare este opţională și desemnează un șir suplimentar, 
incluzând informaţii interpretate de resursă (de cele mai multe ori de un 577). 

De precizat faptul că o serie de caractere sunt rezervate, cum ar fi simbolurile 
i aul ang x D x nO pa vast Sl s Aceste caractere speciale sunt 
codificate conform unei metode denumite URL encoding in care caracterul in 
cauzá este substituit de codul sáu numeric, in baza 16, prefixat de semnul ,,%” 
(de exemplu, ,,~” devine ,,%7E”). 

Un URL poate avea drept sufix un identificator de fragment, precedat 
de caracterul ,,#”, cu scopul de a face referire directa la o parte constituenta 
a resursei adresate de acel URL. Drept exemplificare, se poate da URL-ul 
http:/ | www.portocale.info/ catalog_produse.htmltalbastre. 

O adresă de tip URN desemnează un subset al URI care rămâne permanent 
si unic, chiar dacă resursa a dispărut ori a devenit inaccesibilă. URN-ul se 
utilizează mai ales pentru a desemna entităţi (tipuri de date, spaţii de nume etc.) 
folosite de anumite aplicaţii Web. Drept exemplificări, enumerăm: 


— urn:mozillapackage:communicator identifica pachetele software ale suitei Mozilla; 

— urn:schemas-microsoft-com:datatypes desemnează tipurile de date definite de 
Microsoft; 

— urn:lSBN:978-973-46-0249-0 desemnează numărul ISBN (International Standard 
Book Number) asociat unei cărți. 


Mai general, adresele URI pot preciza resurse care pot fi accesate prin intermediul 
unor diverse protocoale (uzual, cele bazate pe TCP/IP). Astfel, forma generică 


16 SERVICII WEB 


a unui identificator uniform de resurse este schema://autoritate/cale?interogare. O 
setie de exemple de scheme sunt: 


file:///tmp/ — schemă ce desemnează resurse de tip fișier din cadrul sistemului 

de stocare de la nivelul clientului (aici, directorul /7p); 

— _fip://fip.funet.fi/pub/ README.txt — schemă utilizată pentru serviciile pro- 
tocolului de transfer de fișiere (FTP); 

— https: /wwm.infoiasi.ro/ ~busaco/ teach/ — schema pentru serviciile protocolului 
securizat HTTPS — HTTP folosit in conjunctie cu SSL (Secure Sockets Layer) 
sau TLS (Transport Layer Security); 

— mailto:busaco@infoiasi.ro — schema mailto pentru posta electronica; 

— tag:blogger.com,2006:blog-333 — schema destinată să identifice in mod unic (spatial 
si temporal) o anumită resursă, într-o manieră convenabilă pentru utilizator 
(în acest caz, este vorba de subiectele de interes ale unui biog); 

— nuid:d52¢-e8 9c-01f8-3b5 3-a25e-8 Iof-a5 bb-ad17 — schemă care specifică un iden- 

tificator unic universal (UUID — Universal Unique IDentifier) ce desemnează o 

anumită resursă; acest identificator se reprezintă prin 32 de cifre în baza 16 

şi se regăseşte uneori si sub denumirea de GUID (Globally Unique IDentifzer). 


Maniera de codificare a conținutului 


Pentru ca datele să fie corect interpretate de toate entităţile participante la 
conversaţia prin reţea, indiferent de platforma hardware si software, ele trebuie 
să respecte aceeași codificare. 

Astfel, se definește conceptul de set de caractere, pentru a putea interpreta 
corect datele schimbate via protocolul HTTP între două platforme diferite (e.g., 
un server rulând pe un sistem Linux cu un navigator Web de pe un dispozitiv 
mobil), având reprezentări diferite ale datelor. Informaţia e transmisă sub forma 
unui șir de caractere urmând ca entitatea de la celălalt capăt, folosind indicațiile 
despre setul de caractere, să realizeze transformarea din sir de octeți în sir de 
caractere. Setul de caractere implicit este ISO-8859-1, dar există o multitudine de 
alte seturi (de exemplu, ISO-8859-2 denumit si Latin-2, care oferă printre altele 
și reprezentarea diacriticelor din limba română). 

Protocolul HTTP respectă seturile de caractere definite de specificațiile MIME 
(Multipurpose Internet Mail Extensions) descrise în documentele RFC 2045 si 2046. 
Conform standardului MIME, pentru fiecare resursă în parte se specifică tipul si 
subtipul acesteia. De exemplu, 7ex7//// pentru un document HTML, zext/plain 
în cazul unui document text neformatat, image/png pentru o imagine in format 
PNG, application/json în situaţia datelor vehiculate via JSON (JavaScript Object 
Notation), application/ soab-- xml pentru mesajele SOAP (Simple Object Access Protocol) 
si multe altele. 
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De asemenea, mesajele pot fi codificate prin diverse metode, precum $75 ori 
compress, în vederea comprimării sau asigurării identităţii şi/sau integrităţii. 


Mesajele HTTP 


Cererile și răspunsurile HTTP sunt vehiculate prin intermediul mesajelor. Astfel, 
mesajele HTTP sunt considerate de două tipuri: cerere provenită de la un client 
către un server și răspuns al serverului, trimis la acel client. Un mesaj e compus 
dintr-o succesiune de linii de text, delimitate de caracterele CRLF (Carriage Return 
si Line Feed). Prima linie semnifică o cerere efectuată de un client sau un cod de 
stare obţinut de la server, urmată de un număr de atribute de antet. 

Un antet (header) contine mai multe atribute care sunt folosite la completarea 
unei cereri sau a unui răspuns cu meta-informatia necesară interpretării corecte 
a mesajului prin stabilirea unor valori specificate de către protocolul HTTP sau 
a unor protocoale definite de utilizator (de exemplu, SOAP). Un atribut este 
furnizat printr-un nume urmat de ,,:” și de o valoare (opţională, în unele cazuri). 

O cerere e specificată de o metodă de acces, printre cele mai folosite fiind: 


— GET reprezintă o cerere de accesare a unor informaţii (reprezentări de 
resurse). Un client HTTP (navigator, robot, program de descărcare, agregator 
de ştiri, p/ayer multimedia etc.) folosește metoda GET pentru a obţine o 
anumită resursă, fie că ea reprezintă un fișier (document text, HTML, imagine 
PNG sau JPEG, aplicaţie, arhivă, document XML etc.), fie că indică execuţia 
pe serverul Web a unui proces care va produce datele dorite (¢.g., invocarea 
unui script CGI sau a unui program PHP); 

— HEAD este similară cu metoda GET, dar serverul va întoarce un mesaj 
având informaţii doar în antet. Meta-datele din anteturile HTTP din răspunsul 
la o cerere HEAD vor fi identice cu cele din răspunsul la o cerere GET. 
Utilitatea acestei metode constă în obținerea meta-datelor asociate unei resurse 
Web fără a transfera efectiv întreaga entitate, în vederea — de exemplu — a 
testării existenţei resursei, a obţinerii datei ultimei modificări sau furnizarea 
drepturilor de acces; 

— POST este utilizată pentru a identifica dacă serverul acceptă o entitate 
înglobată în cerere. POST este proiectată să implementeze o metodă uniformă 
pentru funcţii precum adnotarea resurselor, trimiterea datelor unui formular 
Web către server, extinderea unei baze de date printr-o operațiune de inserare, 
invocarea unul serviciu etc. 


In cadrul unei cereri pot fi specificate diverse atribute, utilizate pentru a 
transmite serverului informații suplimentare privitoare la acea cerere și la client. 


18 SERVICII WEB 


Se poate face o analogie între trimiterea unei metode HTTP și apelul unei 
funcţii dintr-un limbaj de programare, unde atributele reprezintă parametrii de 
intrare. 

După primirea și interpretarea unui mesaj de tip cerere și interpretarea lui, un 
server HTTP întoarce un mesaj denumit răspuns. Prima linie contine versiunea 
protocolului HTTP implementat de către server si continuă cu un cod de stare 
reprezentând un număr asociat de către specificatia HTTP unei anumite situații 
a serverului în urma tratării unei cereri. Urmează un text explicativ pentru codul 
de stare, menit să clarifice situația exprimată de acesta. 

Codul de stare este format din trei cifre organizate în categorii de stări; 
codurile din aceeași categorie se referă la stări similare. Ele se disting după prima 
cifră în modul următor: 

— Coduri de informare (7xx) — furnizează informaţii privitoare la o anumită 
acțiune (cererea a fost primită, comunicația continuă). De exemplu: 700 
Continue (clientul poate continua cererea, trebuind să trimită următoarea parte 
a unui mesaj parțial). 

— Coduri de succes (2xx) — raportează efectuarea cu succes a unei operațiuni 
(cererea a fost primită, interpretată și acceptată de către server). Un cod tipic 
din această categorie este 200 OK (cererea a fost rezolvată cu succes). Alt 
exemplu este 204 No Content (serverul a rezolvat cererea, dar nu are ce returna 
clientului). 

— Coduri de redirectionare (3xx) — indică o redirectionare a cererii spre altă 
locaţie ori alt server. Drept exemple, menționăm codurile 307 Moved Permanently 
(resursa solicitată a fost asociată unui URI nou și orice referinţă viitoare la ea 
trebuie să se realizeze prin acest URI furnizat) si 302 Moved Temporarily 
(resursa cerută are asociat un alt URI, dar pentru o perioadă temporară). 

— Coduri de eroare provocate de client (42x) — specifică apariţia unei erori pe 
partea clientului (fie cererea este incorectă din punct de vedere sintactic, fie 
nu poate fi satisfăcută din varii motive). Ca exemple, furnizăm 407 Unauthorized 
(cererea necesită autentificarea utilizatorului — e.g., via un nume de cont urmat 
de o parolă) si 403 Forbidden (serverul a recepționat o cerere corectă, dar 
refuză să o satisfacă din diverse motive legate de restricționarea accesului). 
Un alt cod tipic, des întâlnit, este 404 Not found (serverul nu găseşte resursa 
specificată). 

— Coduri de eroare generate de server (xx) — desemnează coduri semnificând 
o eroare pe partea serverului (cererea este aparent corectă, dar serverul nu o 
poate îndeplini din anumite motive). Drept exemplificare menționăm 503 
Service Unavailable (serverul Web nu poate satisface cererea — eg., din cauza 
supraîncărcării temporare sau din rațiuni de administrare). 
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Lista tuturor codurilor de stare este disponibila in specificatiile HTTP. 
In tabelul de mai jos poate fi parcursa lista unora dintre cele mai importante 
atribute care insotesc mesajele HTTP. 


Atribut HTTP Semnificatie 


Specific unei cereri, cu rol în stabilirea tipului conţinutului prin 
intermediul unei negocieri conduse de server; clientul are posi- 
bilitatea de a furniza tipurile media (MIME) pe care acesta le 
recunoaşte si le poate interpreta sau poate indica numai tipul de 


răspunsuri preferate. Un exemplu este Accept: text/xml, 
application/xml 


Accept 


Permite controlul cache-ului, de cele mai multe ori la nivelul 
Cache-Control proxy-ului dintre client şi server — Cache-Control: 
max-age=600 


Atribut general folosit pentru a specifica anumite proprietăți 
legate de conexiune. Se aplică doar comunicaţiei între două 
aplicaţii HTTP din lanţul unor cereri sau răspunsuri. E util in 
implementarea conexiunilor persistente - Connection: close 


Connection 


Desemnează tipul MIME al reprezentării resursei solicitate de un 
Content-Type client ori transmise de server. Un exemplu notoriu este 
Content-Type: text/html 


Folosit într-o cerere pentru specificarea adresei Internet şi a pot- 
Host tului in vederea stabilirii exacte a locatiei unde se află resursa 
căreia i se adresează cererea — Host: www.portocale.info 


Specific răspunsurilor HTTP. Utilizat in conjunctie cu coduri de 
Location stare de tip 2xx sau 207 Created. Poate stabili locaţia curentă sau 
preferată a resursei sub forma unui URI absolut. 


Conţine informaţii despre aplicaţia server, cum ar fi numele, 
Server versiunea, producătorul, aplicaţiile compatibile — Server: 
libwww-perl-daemon/1.36 


2. Arhitectura orientată spre servicii Web 


2.1. Introducere 


Sistemul pe care rulează un server Web si care găzduiește o serie de pagini 
(documente) WWW înrudite — ale unei organizaţii, companii sau persoane — se 
numește sit (s). Această colecţie este orientată, de obicei, către anumite 
informaţii unitare sau scopuri comune. 

Din punctul de vedere al vizibilitátii, un sit Web poate fi disponibil doar in 
cadrul unui îpfranef (reţeaua internă proprie unei companii sau organizaţii) și/sau 
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in extranet (extindere a facilitatilor intranetului prin mijlocirea comunicatiilor 
între intraneturile a două sau mai multe organizaţii). 

O aplicație Web reprezintă o colecţie interconectatá de pagini Web cu un 
conţinut dinamic, menită să ofere o funcţionalitate specifică utilizatorilor. Natural, 
interacțiunea dintre aplicaţie si utilizatori are loc prin intermediul unei interfeţe 
Web. Deseori, termenii de sit si aplicaţie Web sunt folosiţi unul în locul celuilalt, 
pentru a desemna același concept. Drept exemple de aplicaţii Web pot fi 
enumerate Amazon, Basecamp, eBay, Expedia, Flickr, Google Maps, PHPMyAdmin, 
Wikipedia, Yahoo! si multe altele. 


2.2. Programarea aplicatiilor Web 


Devine evident faptul că trebuie recurs la un mecanism de generare dinamică a 
conţinutului Web redat utilizatorului, prin intermediul browser-ului, în funcție de 
datele de intrare, de modul de navigare printr-un sit si de diversi alti factori 
(autentificare, integrare de conţinuturi preluate de pe alte situri, preferinţe etc.). 
Informaţiile puse la dispoziţie pot fi eterogene, provenind din surse de date 
multiple (fişiere text, baze de date, documente XML, s¢ream-uri multimedia, 
arhive software, rezultate ale unor operaţii efectuate la distanţă, pe alte calcu- 
latoare, si asa mai departe). 

Din punct de vedere istoric, prima metodă de generare dinamică pe server a 
reprezentărilor unor resurse solicitate de un client Web vizează standardul de facto 
CGI (Common Gateway Interface). Principalele dezavantaje sunt cele privitoare la 
invocarea concurentă a mai multor serpruri CGI, problemele survenite fiind 
asigurarea scalabilitatii, a integrării cu alte aplicaţii, persistenta conexiunii și 
contextul invocării (rulării). 

Evoluţia a continuat cu apariția altor interfețe de programare Web pe partea 
de server. Astfel, pot fi menţionate mod_perl pentru Apache, NSAPI (Nezscape 
Server APD si ISAPI (Microsoft Internet Services APD, funcţionând intern conform 
modelului CGI. Ulterior a apărut si tehnologia serv/ef-urilor Java. 

De un succes larg se bucură însă mediile și framework-urile care facilitează 
dezvoltarea de aplicații Web, printre cele mai populare numărându-se ASP 
(Active Server Pages), ASP.NET (parte integrantă a .NET Framework), PHP (PHP: 
Hypertext Prepocessor) si JSP (Java Server Pages). Principalele avantaje ale acestora 
fata de vechiul, dar inca utilizatul CGI, sunt următoarele: suportul pentru 
sesiuni, asigurarea /oad-bal/ancing-ului, conexiunile persistente cu sistemele de baze 
de date, suportul pentru femp/aze-uri de interfață, facilităţile vizând modularitatea, 
securitatea etc. Desigur, în unele situaţii pot fi folosite și cadre de lucru adiționale. 
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2.3. Servicii Web. Punerea problemei 


Premise 


După cum am mai menționat, originile si scopurile Web-ului iau în considerare 
constituirea unui spațiu de comunicare interumană prin intermediul partajării 
cunoștințelor si exploatarea puterii computationale puse la dispoziție de calcu- 
latoarele interconectate. Se poate observa cu ușurință faptul că interacțiunea 
dintre om si Web se rezolvă prin intermediul formularelor si legăturilor hipertext, 
iar interacțiunea dintre masini se desfăşoară pe Web într-o manieră limitată. 

O primă abordare este aceea de a recurge la un mecanism care să ne permită 
apelarea unor operații menite a fi executate la distanță. Astfel, un program client 
poate să invoce proceduri (metode, funcționalități) pe alte calculatoare din rețea. 
Această soluție este oferită de paradigma RPC (Remote Procedure Call, pe care o 
vom prezenta pe scurt în cadrul următoarei secțiuni. 


RPC (Remote Procedure Call) 


Mecanismul RPC a apărut cu mai bine de două decenii în urmă în lumea UNIX 
şi a fost/este folosit în construcția de aplicații distribuite pe sisteme eterogene, 
având la bază tehnologiile Internet. 

Paradigma RPC conferă forţă modelului client/server și constituie un instru- 
ment de programare mai simplu fata de abordarea clasică oferită de sockef-uti. 
Dacă în mod obișnuit modelul client/server se axează mai mult pe partea de 
comunicaţie între procese aflate pe mașini diferite, RPC este mai aproape de 
proiectarea clasică a aplicaţiilor, programatorul focalizându-se pe logica pro- 
gramului si abia la final divizând aplicaţia in componente și adăugând suportul 
de comunicare în reţea. 

O aplicaţie RPC va consta dintr-un client si un server, serverul fiind localizat 
pe mașina care execută procedura. Aplicația client comunică prin reţea — via 
TCP/IP — cu procedura de pe calculatorul aflat la distanță, transmițând argu- 
mentele si receptionand rezultatele. Clientul si serverul se execută ca două 
procese separate care pot rula pe calculatoare diferite din reţea. 

Aceste procese client si server comunică in mod transparent, prin intermediul 
a două interfeţe numite cof (stub): va exista deci un s/wb pentru client și altul 
pentru server. Interfetele implementează protocolul RPC, care specifică modul 
cum se construiesc și cum se prelucrează mesajele emise între procesele client si 
server. S/wb-urile se generează de obicei cu ajutorul unui utilitar, după care se 
„leagă” de programele client si server. Fișierele szub contin funcţii care translateazá 
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(de obicei, fara aportul programatorului) apelurile locale de procedura intr-o 
secventa de apeluri de functii RPC de retea. Astfel, din punctul nostru de vedere, 
totul se considera a fi un simplu apel local. Clientul ,,cheamá" procedurile din 
stub-ul său prin care utilizează biblioteca RPC pentru a găsi procesul la distanţă, 
urmând ca apoi să-i transmită cereri. Procesul la distanţă „ascultă” reţeaua prin 
intermediul s7/b-ului propriu. Szub-ul serverului realizează invocarea rutinelor 
dorite cu ajutorul unei interfeţe de apel de proceduri locale. 

Clientul și serverul trebuie să comunice prin mesaje, utilizând o reprezentare 
a datelor independentă de calculator și de sistemul de operare. RPC adoptă un 
format propriu pentru reprezentarea datelor, cunoscut sub numele de XDR 
(External Data Representation) si descris pe larg în documentul RFC 1014. Tipurile 
standard suportate de XDR sunt cele uzuale din limbajul C (precum 474, unsigned 
int, float sau void), plus altele, suplimentare. Szub-urile client si server sunt 
responsabile si cu translatarea in si din acest format. Se permite translatarea 
tipurilor predefinite din C, precum și a unor tipuri mai complexe, cum ar fi 
vectorii de lungime variabilă. Operația de (de)codificare se numește (de)serializare 
sau (un)marsballing. 

O facilitate importantá oferita de RPC este ascunderea in totalitate a pro- 
cedurilor de reţea în interiorul interfetelor sub. Acest aspect conduce la simplifi- 
carea programelor client si server, eliminándu-se necesitatea de a controla detaliile 
legate de comunicarea în reţea. Deoarece sistemul RPC încearcă să ascundă 
detalii legate de reţea, el include de obicei o convenţie legată de schimbul de 
argumente si rezultate între client si server, mărindu-se astfel gradul de porta- 
bilitate a aplicaţiilor. 

Astfel, RPC pune premisele oferirii de servicii (a căror implementare nu 
trebuie să fie cunoscută de către clientul care dorește să-l folosească), adresele 
clientului, serverului și numele serviciilor fiind păstrate la nivel simbolic. Un 
serviciu de reţea este identificat prin portul la care este oferit si unde există un 
daemon (proces care rulează în fundal) așteptând cererile de conectare. Un port 
în viziunea RPC reprezintă un canal logic de comunicare. Comunicarea cu 
serviciul se realizează via XDR, vehicularea datelor decurgând la nivel binar, 
conform unor reguli prestabilite de codificare, independente de platformă. 

Există mai multe implementări ale paradigmei RPC. Prima, de referinţă, a fost 
oferită de corporatia Sun Microsystems, fiind denumită Open Network Computing 
RPC (ONC RPC) — aceasta este de altfel cea mai răspândită implementare pentru 
UNIX/Linux (detalii în RFC 1057). Procedurile la distanță se vor include într-un 
program la distanta. Un program aflat la distanta reprezinta unitatea software 
care se va executa pe o mașină aflată la distanţă. Fiecare program aflat la distanță 
corespunde unui server, putând conţine un set de una sau mai multe proceduri 
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la distanţă ori date globale. Procedurile pot partaja date comune. De remarcat 
faptul ca argumentele pasate procedurilor la distanta trebuie sa fie incapsulate 
într-o structură (similară cu struct din limbajul C) pentru a reduce numărul de 
argumente transmise procedurii. 

Fiecărui program aflat la distanţă i se va asocia un identificator unic, stocat 
pe 32 de biţi, iar fiecare procedură componentă (care va fi executată în cadrul 
acelui program) este numerotată (indexată) secvențial de la 1 la 7, unde 7 este 
numărul maxim de proceduri ale acelui program. De asemenea, fiecare program 
la distanţă va fi însoţit de un număr întreg pozitiv desemnând versiunea. Prima 
versiune a unui program de obicei este 1. Următoarele versiuni vor fi identificate 
de alte numere, în mod unic. Numerele de versiuni oferă posibilitatea de a 
schimba detaliile de implementare sau extinderea capabilitatilor aplicațiilor fără 
a asocia unui program un identificator diferit. 

Mecanismul RPC isi găsește utilizări interesante, dintre care, cea mai impor- 
tanta o reprezintă accesul la sisteme de fişiere la distanță prin NFS (Network File 
System), prezent in orice mediu UNIX si semnificand de fapt un sistem de fisiere 
distribuit (distributed file system). 

O alternativă la ONC RPC este mediul de calcul distribuit DCE (Distributed 
Computing Environment), cate constituie şi fundamentul unor servicii de reţea 
vitale din Windows 2000/XP. 

În anii 90, RPC a continuat să fie utilizat prin abordarea obiectuală ORPC 
(Object RPC), mesajele de cerere și răspuns de la distanţă fiind incapsulate de 
obiecte. Ca descendenţi direcți ai ORPC se pot enumera DCOM (Distributed 
Common Object Model) si IIOP (CORBA Internet Inter-ORB Protocol). Arhitectura 
Java pune la dispoziție RMI (Remote Method Invocation), iar platforma .NET oferă 
așa-numitul NET Remoting. 


Necesitatea unei arhitecturi orientate spre servicii. Caracterizare 


Odată cu proliferarea aplicaţiilor Web, dezvoltatorii şi-au dat seama că nevoile 
industriei de profil au crescut, dorindu-se existența unor soluţii multi-platformă 
slab-conectate. Acestea conduc la integrarea aplicațiilor, serviciilor și sistemelor, 
prin folosirea tehnologiilor Web actuale. Această integrare trebuie să se realizeze 
într-un mod flexibil, ad hoc, în funcţie de necesităţi. De asemenea, trebuie atins 
un grad înalt de performanţă prin asigurarea scalabilitatii si e necesară existența 
unui suport pentru crearea și exploatarea unor servicii atasabile (p/ugeable) si 
inteligente"; software-ul fiind văzut în termeni de serviciu si nu drept aplicaţie 
mamut („software as service”). 

Aceasta pune premisele constituirii unor ofertanti de servicii de aplicaţii 
(application service provider). De asemenea, apare necesitatea proiectării si (re)folosirii 
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unor standarde pentru indeplinirea cerintelor legate de vehicularea, disponi- 
bilitatea, mentenanta, securitatea si regăsirea datelor. 

Spatiul Web poate fi considerat din acest punct de vedere ca o tehnologie 
middleware, extensie a unor modele precum CORBA sau DCOM (a se urmări și 
figura 1). Componentele intermediare (prox)) la nivel de client și server pot juca 
același rol ca interfețele stub RPC. 


Figura 1. Spafiul Web ca tehnologie middleware 


Mai mult decat atat, trebuie puse bazele constituirii unei arhitecturi destinate 
dezvoltarii de aplicatii distribuite orientate spre Web. Software-ul trebuie divizat 
în servicii care se pot compune, menite a se conecta și orchestra in mod spontan 
în cadrul proceselor de afaceri sau din alte medii. Este o viziune a software-ului 
bazat pe componente Web (component-based software), în contrast cu aplicaţiile 
monolitice, clasice. Desigur, software-ul standard (,vechi") trebuie integrat în 
această nouă arhitectură pentru a se proteja investiţiile făcute. 

Soluţia este dată de un model cunoscut sub numele de arhitectura orientată spre 
servicii (SOA — Service Oriented Architecture). Arhitectura SOA impune adoptarea 
unui stil de dezvoltare de aplicaţii, considerate drept servicii ce vor fi invocate 
de alte aplicaţii. Conform OMG (Object Management Group), definiţia — propusă în 
aprilie 2006 — a arhitecturii orientată spre servicii este următoarea: SOA reprezintă 
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un stil arhitectural de obtinere a unor valori mutuale de catre comunitatile de 
ofertanti și consumatori de servicii, permiţând participanţilor la aceste comunități 
de interese să conlucreze într-o manieră cât mai puţin dependentă de tehnologie. 
Acest stil specifică, de asemenea, contractele pe care organizaţiile, oamenii și 
tehnologiile respective trebuie să le respecte în vederea participării în cadrul 
comunităţii, în vederea obţinerii de valori de tip business si derulării de procese de 
afaceri. Facilitarea interacțiunilor în cadrul comunităţii trebuie să se facă prin 
intermediul unei varietăţi de tehnologii (prezente și viitoare). 

Conform enciclopediei colaborative deschise Wikipedia, prin SOA se înţelege 
o perspectivă asupra unei arhitecturi software care definește utilizarea de servicii, 
oferind funcționalități solicitate de utilizatori. Resursele reţelei sunt astfel dis- 
ponibile graţie unei suite de servicii independente ale căror implementări sunt 
necunoscute. 

SOA presupune că noile servicii pot fi create pe baza celor deja existente, 
într-o manieră sinergică, dar componentele sistemului în ansamblu trebuie să 
aibă un grad mare de independenţă (de-coupling). În funcţie de schimbările ce 
pot interveni în cerințe (business requirements), serviciile pot fi recompuse sau 
orchestrate diferit. 

Principiile de bază impuse de prevederile SOA sunt: 


— serviciile trebuie să partajeze un contract formal; 

— serviciile trebuie să fie slab conectate (/oosely coupled); 

— serviciile trebuie să ascundă dezvoltatorului detaliile de implementare; 

— serviciile trebuie să ofere suport pentru compunerea cu alte servicii 
(composability); 

— serviciile trebuie să poată fi reutilizate; 

— serviciile trebuie să se execute într-un mod autonom; 

— serviciile nu trebuie să depindă de starea comunicării (statelessness), cantitatea 
de informaţie specifică unei activităţi ce trebuie reținută fiind minimală; 

— serviciile trebuie să poată fi facil descoperite (discoverability). 


Astfel, arhitectura SOA trebuie să suporte între aplicaţii paradigme de 
comunicare bazate pe Web să ofere o localizare transparentă a serviciilor și să 
permită adăugarea, înlocuirea și eliminarea serviciilor în mod dinamic. 

Prin intermediul SOA, consumatorii de servicii nu sunt dependenţi de 
ofertantii de servicii, putând avea acces la o paletă largă de servicii oferind 
aceleași funcţionalităţi dorite. Serviciul poate fi văzut doar drept interfaţă, 
maniera de procesare (business /ogic) putând fi separată de serviciul propriu-zis. 

Via SOA, utilizarea și descoperirea serviciilor se pot realiza în mod dinamic, 
facilitându-se integrarea la nivel de aplicații (A2A — Application to Application) 
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si/sau de afaceri (B2B — Business to Business). Suplimentar, prin intermediul 
serviciilor se poate realiza managementul proceselor de afaceri (BPM — Business 
Process Management). 

Metodologia de proiectare și dezvoltare a aplicaţiilor aliniate prevederilor 
SOA poartă numele de SOAD (Service-Oriented Analysis and Design). Una dintre 
propunerile de astfel de metodologii este cea publicată de IBM în 2004 — SOMA 
(Service-Oriented Modelling and Architecture). 


2.4. Conceptul de serviciu Web bazat pe XML 


Precursori 


În mod obişnuit, putem implementa serviciile Web recurgánd la script-uri CGI 
sau diverse servere de aplicaţii. Interacțiunea tradițională poate decurge in 
următoarele două moduri. 

Prima manieră este cea funcţională (de tip cerere/răspuns): utilizatorul (nu 
neapărat uman) vizitează o pagină și formulează o cerere, fie traversând o 
legătură hipertext, fie prin intermediul unui formular. Serviciul (implementat de 
un program conceput într-un anumit limbaj, precum Perl, PHP, C# ori Java) 
întoarce un răspuns, adică o reprezentare — uzual, marcată in HTML — a resursei 
solicitate. Astfel, se accesează de la nivelul clientului o anumită funcţionalitate 
specifică pusă la dispoziţie de un server Web. 

Cea de a doua este una conversationala (de tip solicitare/răspuns). Suplimen- 
tar, se dă posibilitatea exprimării unor întrebări adiţionale în vederea rafinării 
cererii: serviciul solicită date de la utilizator pentru a returna un răspuns mai bun. 

Se poate observa că serviciul Web, respectând ,traditia", expune o interfata- 
-utilizator (concepută în limbajul de marcare HTML în marea majoritate a 
cazurilor) prin intermediul căreia are loc interacțiunea. Cererile sunt captate via 
formulare, utilizatorii umani trebuind să interpreteze etichetele (/abe/s) atașate 
câmpurilor de dialog, pentru a cunoaște ce tipuri de date pot fi introduse (se 
asigură câmpuri textuale, liste de opţiuni, butoane de tip checkbox si radio etc.). De 
asemenea, utilizatorii umani trebuie să interpreteze răspunsul oferit de serviciu 
prin parcurgerea rezultatului redării de către browser a reprezentării (HTML) 
expediate de server. 

Pentru un calculator, activitățile expuse mai sus sunt dificil de realizat, 
deoarece programul de interpretare a rezultatului depinde de succesiunea de 
marcaje ale paginii Web recepționate. Orice modificare, minora sau nu, a /ag-urilor 
din cadrul documentului conduce la rescrierea serpr-ului de prelucrare a ieșirii 
oferite de serverul Web. Această metodă de „capturare” a informaţiilor incluse 
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intr-un document HTML se mai numeste si Web/HTML scrapping si se dovedeste 
dificil de aplicat in cazul receptarii de structuri complexe de date. 


Definiţii si caracterizări 


Serviciile Web bazate pe XML (Extensible Markup Language) fac explicite spe- 
cificatiile implicite, putand fi folosite in cadrul interactiunii dintre masini. Mai 
mult decât atât, pot fi invocate si în cazul necunoasterii a priori a interacțiunii cu 
alte aplicaţii /servicii Web. 

Nu există o definiție unanim acceptată a conceptului de serviciu Web. 
Conform IBM, reprezintă o aplicaţie modulară bazată pe tehnologiile Internet, 
menită a îndeplini activități specifice și conformându-se unui format tehnic 
specific. Microsoft consideră serviciile Web ca fiind partea de procesare a datelor 
unei aplicații (application /ogic) disponibilă la nivel de program și beneficiind de 
functionalitatile oferite de Internet. După Sun, un serviciu Web este o aplicație 
care acceptă cereri din partea altor sisteme dispuse în Internet sau intranet, 
mediate de tehnologii de comunicaţie neutre si agile. 

Un serviciu Web oferă o funcţionalitate specifică accesată pe baza unui 
schimb de mesaje marcate în XML. Acest schimb de mesaje e guvernat de 
anumite reguli. Suplimentar, un serviciu Web se poate autodescrie, folosind 
meta-date (date referitoare la date). 

Serviciile Web implică utilizarea unor protocoale de comunicaţie, având 
asociate descrieri ale datelor procesate si alte interacțiuni cu aplicaţii terțe. 
Identificarea unui serviciu Web se realizează prin intermediul URI-urilor; transfe- 
rul de date recurge în mod uzual la HTTP, iar definirea structurată a datelor 
vehiculate se face via XML. Un serviciu Web poate fi considerat ca fiind compus 
dintr-o colecție de funcții împachetate, interpretate ca o entitate unică și publicate 
în spaţiul WWW cu scopul de a fi folosite de alte programe. 

Ca exemple de operaţii ce pot fi puse la dispoziţie de serviciile Web, le 
amintim pe următoarele: 


— transformarea datelor primite (eg, conversii de valori în alte unități de măsură); 

— dirijarea mesajelor (mai ales în cazul ,,magistralelor” de date specifice, 
disponibile la nivel de întreprindere); 

—  interogări asupra diverselor servere de baze de date relationale, obiectuale sau 
native XML (de exemplu, furnizarea cataloagelor de produse, a coordonatelor 
unor localități, a situaţiei unui cont bancar, a istoricului cumpáráturilor 
efectuate online etc.); 

— orchestrarea conversatiilor între diferite entități (jucând, din acest punct de 
vedere, rolul de mediatori sau agenţi); 
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realizarea de procesari (calcule) diverse; 

aplicarea de politici de acces asupra resurselor; 

rezolvarea unor excepţii ce pot surveni într-un context; 

solicitarea de aprobări de la utilizator (eg., a execuţiei unor aplicaţii de către 
o altă entitate). 


Drept principale caracteristici ale serviciilor Web menţionăm: 


accesarea, în manieră publică, se realizează printr-o adresă; serviciile Web pot fi 
considerate ca reprezentând puncte terminale (end points) ale comunicării între 
masini, similar modelului folosit de protocoalele de transport ale stivei TCP/IP; 
abilitatea de a prelucra orice tip de date, din moment ce datele de intrare sunt 
documente XML (conforme unei scheme de validare); 

posibilitățile de dezvoltare pe baza platformelor, arhitecturilor și limbajelor 
existente; 

adaptabilitatea (un serviciu Web poate fi extins, utilizând eventual, în mod 
transparent, alte aplicaţii sau invocând la rândul său alte servicii Web). 


Serviciile Web sunt cărămizile pentru crearea de sisteme distribuite deschise, 


permiţând organizaţiilor și dezvoltatorilor independenţi să-și facă disponibile pe 
Web bunurile digitale într-un mod rapid si facil. 


Mai mult, serviciile Web separă modul de prezentare a datelor de partea de 


prelucrare a acestora, fiind aliniate sablonului de proiectare MVC (Model-View- 
-Controller, des întâlnit în domeniul ingineriei programării. Modulul de inter- 


acţiune cu utilizatorul (componenta view) este separat de cel de procesare (model), 


reprezentat de serviciul Web în sine, comunicarea fiind facilitată de un strat de 


control (controller) — a se urmări figura 2. Astfel, rezultatele preluate de la serviciul 


Web, ce oferă o anumită funcţionalitate aplicaţiei noastre, pot fi redate utili- 


zatorului într-o multitudine de forme, fără a trebui să modificăm (sau să avem 


măcar acces la) implementarea serviciului. 


View Controller Model 


mijloc de 


comunicare 


Figura 2. Interacțiunea între un serviciu Web şi un client, 


prin prisma MVC 
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Orice aplicatie-client (script Perl, applet Java, program C cu interfață text sau 
grafică, aplicație .NET, pagina ori serviciu Web etc.) poate „consuma” — într-o 
varietate de modalități — datele obţinute de la un serviciu invocat printr-o 
metodă standardizată, bazată pe normele Web în vigoare. 

Desigur, în afară de avantajele incontestabile oferite (inter-operabilitate între 
diverse platforme și limbaje de programare, utilizarea de standarde si protocoale 
deschise, reutilizarea componentelor software, lipsa unei relații strânse între 
entităţi etc.), serviciile Web pot prezenta și dezavantaje, precum lipsa ori suportul 
precar pentru tranzacţii si performanţa relativ scăzută fata de abordările binare 
(CORBA, DCOM ori RMD). 

Odată cu proliferarea arhitecturii SOA, sunt disponibile servicii specifice 
mediului enterprise, vizând aspecte legate de: 


— conţinut — specificarea, colectarea și organizarea cunoștințelor din cadrul 
Organizaţiei; 

— acces — utilizatorii, via un portal/desktop Web, vor avea la îndemână mijloacele 
de creare și de exploatare a serviciilor sau aplicaţiilor compuse; 

— integrare — în contextul EAI (Enterprise Application Integration) îndeosebi, 
conţinutul vehiculat de aplicatii/utilizatori va putea fi transformat graţie unor 
entități software inteligente; 

— procesare — se vor putea specifica reguli pentru managementul traficului de 
date (dirijare, caching, filtrare etc.) în funcţie de specificul afacerilor întreprinse; 

— analizare — acordarea unui suport avansat de luare (inteligentă) a deciziilor; 

— colaborare — va putea fi instituită o fundaţie pentru managementul inter- 
acțiunilor și comunicaţiilor între utilizatori (umani sau nu) — un exemplu în 
acest sens este enterprise wiki. 


XML pentru servicii Web: SOAP, WSDL si UDDI 


Vom prezenta în continuare principalele componente folosite in invocarea, 
definirea si regăsirea serviciilor Web. 

În primul rând, apare necesitatea dezvoltării unui protocol de comunicare (transport) 
între mașini eterogene care să faciliteze vehicularea de mesaje permiţând inter- 
acţiunile complexe dintre calculatoare și având un conţinut oricât de complex. 
Mai mult decât atât, trebuie oferit suport pentru asigurarea extensibilitatii, 
luându-se în calcul problemele de securitate, fiabilitate și performanţă ce pot 
surveni. Acest protocol va trebui să pună la dispoziție un mecanism de //7vocare 
si de /ransmifere structurată a datelor. 

Trebuie, astfel, găsit un limbaj pentru transmisia în format XML a parametrilor 
de intrare și întoarcerea răspunsului primit de la serviciul Web invocat. 
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Figura 3. Nivelurile de standardizare a serviciilor Web 


Principalele protocoale de comunicare utilizate in prezent sunt XML-RPC si 
SOAP. 

XML-RPC oferă o specificaţie si un set de implementări pentru realizarea de 
apeluri de proceduri la distantá, in spiritul mecanismului RPC descris succint mai 
sus. A fost proiectat pentru a fi cát mai simplu, in acelasi timp insá permitand 
si transmiterea, procesarea si returnarea unor structuri complexe. In mod succint, 
putem considera ecuaţia: XML-RPC = HTTP + XML + RPC. 

SOAP (Simple Object Access Protocol) reprezintă o recomandare a Consortiului 
Web, propunând facilități sofisticate și oferind o paletă largă de posibilități de 
reprezentare (serializare si deserializare) a datelor vehiculate. 

Un mesaj SOAP este compus din trei parti: un pc (envelope), un set de reguli 
de codificare (encoding rules) şi o convenție de reprezentare (representation). Plicul defineşte 
cadrul de lucru pentru a descrie ceea ce conţine mesajul și modul de procesare 
a acestui conţinut. Datele din corpul mesajului pot fi transportate indiferent de 
protocol (uzual, se recurge la HTTP). Regulile de codificare sunt de folos la 
exprimarea instanţelor tipurilor de date definite în aplicaţie, iar convenţia de 
reprezentare este utilizată în contextul apelurilor de metode implementate de 
serviciul Web si al răspunsurilor furnizate în urma invocarii acestora. 
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De asemenea, SOAP poate specifica si o cale de la expeditor la destinatar, via 
un intermediar (proxy) optional, în vederea realizării de dirijări de mesaje (SOAP 
routing). Detalii sunt disponibile în capitolul 4 al lucrării de fata. 

Protocolul SOAP poate fi privit din mai multe perspective. Prima ar fi aceea 
in care poate reprezenta o extindere obiectuală a paradigmei RPC: cererea și 
răspunsul contin parametrii de intrare/ieșire, suplimentar fiind indicate, via 
XML Schema, tipurile de date ale acestora. A doua consideră SOAP ca fiind un 
protocol de mesagerie (serializare), cererea incluzând un obiect-cerere serializat, 
iar răspunsul stocând un obiect-răspuns serializat. Cel de-al treilea punct de 
vedere — prezent si în cazul REST (vezi infra) — admite o tranzacție SOAP ca 
fiind o transformare XSLT la distanță („XSLT with a long wire”): cererea este un 
document XML, iar serverul returnează, ca rezultat al invocării serviciului, o 
versiune XML transformată a cererii. Desigur, nici una dintre aceste abordări nu 
este impusă de protocol. 

În vederea exploatării functionalitatilor puse la dispoziţie de un serviciu 
Web, trebuie oferită o descriere a acestuia. Apare necesitatea unui //pbaj de 
descriere, menit a răspunde la întrebări precum „Care e sintaxa mesajelor 
vehiculate?", „Cum se desfășoară transferul de date?" și „Cum găsim un 
serviciu Web?". 

Soluţia este furnizată de WSDL (Web Semice Description Language). Limbajul 
oferă separarea descrierii abstracte a functionalitatii oferite de un serviciu de 
detaliile concrete (de tipul ,,cum" si „unde” este disponibilă acea funcționalitate). 
WSDL descrie serviciile Web începând cu mesajele interschimbate între entitatea 
care oferă și cea care invocă un anumit serviciu. Mesajele sunt specificate în 
manieră abstractă si apoi sunt asociate unui protocol de reţea, precizandu-se de 
asemenea si un format (o sintaxă). Un mesaj constă dintr-o colecție de date de 
anumite tipuri, iar schimbul de mesaje este descris ca o operaţie. Tipurile de date 
se definesc via scheme XML, la nivel conceptual folosindu-se un model de date 
reprezentat printr-un set de componente (mesaj, port, manieră de atasare, 
serviciu) având specificate diverse proprietăţi. La nivel sintactic se recurge la 
XML. Mai multe amănunte privind WSDL vor fi oferite în capitolul 3. 

Apare încă o cerinţă: instituirea unui mecanism pentru publicarea si regăsirea, 
în manieră publică, a unui serviciu Web. Este posibil ca o anumită funcționalitate 
oferită de un grup de servicii Web să poată fi regăsită prin intermediul unor 
interogări formulate de partea care intenționează să folosească acea func- 
tionalitate. 

Pentru aceasta s-a constituit un catalog al tuturor furnizorilor de servicii Web 
publice in vederea regásirii informaţiilor dorite: UDDI (Universal Description, 
Discovery, and Integration), oferind o bază de date distribuită a serviciilor Web din 
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prisma tipurilor de afaceri electronice pe care acestea le pot modela. Conceptual, 
datele stocate într-un catalog UDDI pot fi împărţite în următoarele trei categorii: 


— paginile albe (white pages) semnifică informaţii generale referitoare la o com- 
panie furnizoare de servicii (numele companiei, descrierea tipurilor de afaceri 
efectuate, adresa etc.); 

— paginile aurii (yelow pages) includ scheme de clasificare a companiilor și/sau 
serviciilor disponibile (de exemplu, coduri de clasificare pe criterii geografice, ale 
categoriei de afaceri, taxonomii referitoare la produsele comercializate și altele); 

— paginile verzi (green pages) precizează informaţii tehnice despre un serviciu 
Web specific (eg, o adresă Web spre descrierea acestuia, o adresă privitoare 
la invocarea serviciului etc.). 


Uzual, căutarea în cadrul UDDI se realizează în funcţie de clasa din care face 
parte afacerea, după un nume de serviciu sau după locaţia geografică a furni- 
zorului. Detalii sunt furnizate în capitolul 5. 


1. căutarea unui 


serviciu Web 2. returnarea 


UR F-ului serviciului 


A E 4. trimiterea unei cereri SOAP 


Serviciu 
Web 


Figura 3. Re/afiie dintre un client, un serviciu Web si registrul UDDI interogat prin SOAP 
pentru a se obtine descrierea WSDL a serviciului dorit 


PREZENTARE GENERALA A SERVICIILOR WEB 33 


Functionalitatile de căutare sunt implementate via servicii Web, astfel încât 
accesul la registrul UDDI se realizează prin intermediul protocolului SOAP 
descris mai sus. UDDI va pune la dispoziţie documentul WSDL corespunzător 
unui serviciu compatibil cu cererea formulată — a se vedea și figura 3. 


Arhitectura REST 


REST (REpresentational State Transfer) reprezintă o arhitectură de dezvoltare a 
aplicaţiilor Web. Conform filosofiei REST, rezultatul unei procesări conduce la 
returnarea unei reprezentări a unei resurse Web. Orice accesare a unei reprezentări 
plasează aplicatia-client într-o stare care va fi schimbată în urma unui /ransfer de 
date (accesarea altei reprezentări, pe baza traversării unei legături hipertext — 
desemnată de un URI — inclusă în reprezentarea resursei initiale). Starea 
comunicării între mesajele vehiculate între server și client nu trebuie reținută 
(stateless). 

Transferul de date se realizează prin HTTP, reprezentarea este marcată in 
XML (ori alt format), iar adresabilitatea se rezolva via URI, spatiul Web putand 
fi considerat drept un sistem REST. 

Serviciile Web actuale se pot dezvolta in concordanta cu arhitectura REST. 
Componentele care invocă funcţionalităţi vor consuma reprezentări de resurse 
(in stilul 54/) conform clasicei arhitecturi client/server. Fiecare cerere este 
considerată independentă, fără a se lua în consideraţie contextul — conexiuni 
stateless. Resursele Web pot fi accesate printr-o interfață generică pusă la dispoziţie 
de metodele protocolului HTTP: GET, POST, PUT și DELETE. Actualmente 
sunt utilizate preponderent GET și POST. 

REST se consideră a fi o viziune complementară de implementare și utilizare 
a serviciilor Web, în locul mesajelor SOAP (al căror format e considerat de unii 
dezvoltatori prea complex în anumite situaţii) recurgându-se la reprezentări 
XML mai simple — numite si POX (Plain Old XML). O astfel de abordare e 
adoptată şi de suita de tehnologii AJAX, prezentată în cadrul capitolului 6. 

O aplicație Web dezvoltată conform principiilor REST are o arhitectură 
diferită de una în stilul RPC (acesta din urmă fiind adoptat si de protocolul 
SOAP). În cazul RPC, punctul focal e reprezentat de mulţimea de operaţii ce pot 
fi executate (numite și verbe), pe când în viziunea REST totul se axează pe 
diversitatea resurselor disponibile (denumite și substantive). 

De exemplu, pentru o aplicație Web privitoare la un sit de comerț electronic 
oferind sortimente de portocale, abordarea SOAP relevă existența unor operaţii 
(metode) precum furnizeazaSortiment(), adaugaS ortiment(), eliminaSortiment(), actualizeaza- 
Sortiment(), listeagaSortimente(), cautaS ortimente() — privitoare la sortimentele disponibile — 
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și furnizeazaUrilizator(), adaugaUtihzator(), eliminaUtihzator(), listeagaUtilizatori() şi 
cautaUtilizatori() — referitoare la utilizatorii (clienții) magazinului virtual. Toate 
aceste funcționalități pot fi implementate de un serviciu Web bazat pe SOAP. 
Recurgând la REST, vom defini doar două tipuri de resurse (Sortiment şi Utilizator), 
fiecare identificată unic de un URI (de exemplu, ///p:/ / www. portocale.info/ sortimente / 
Japoneze). O resursă poate avea asociate reprezentări XML ce pot fi accesate ort 
alterate. Astfel, prin intermediul unor operaţii HTTP standard, putem manipula 
uşor resursele. În acest mod, via GET putem obţine o copie a reprezentării unei 
resurse, cu PUT actualizám o resursă, iar prin DELETE o stergem de pe server. 
Metoda POST se folosește pentru acţiuni care ar putea avea posibile efecte 
colaterale (side effects) — de exemplu, realizarea unei comenzi de plată a sorti- 
mentelor de portocale dorite. 

După cum se observă, interfaţa oferită de HTTP este una generică, oferind 
suport pentru operaţiile de bază, de tip CRUD (Create, Retrieve, Update, Delete) — 
creare, accesare, actualizare si ștergere. 

Actualmente, există numeroase organizaţii care își pun la dispoziţie serviciile 
via o interfață REST. Ca exemple notabile, menționăm Amazon, Bloglines, del.icio.us, 
eBay, Google si Yahoo!. De asemenea, pot fi folosite diverse cadre de lucru pentru 
dezvoltarea de aplicaţii Web în stilul REST: JAX-WS (Java API for XML: Web 
Services), Tonic (pentru PHP), Ruby on Rails, Zope (pentru Python) etc. 


2.5. Modalitatile de implementare si exploatare 


Existenţa serviciilor Web este insuficientă fără a avea la îndemână instrumente 
suplimentare de implementare, exploatare și integrare. Un aspect important este 
dat de faptul că informaţiile și serviciile trebuie să fie accesibile de pe orice tip 
de calculator și de oriunde, apărând astfel necesitatea utilizării unei platforme 
independente de dispozitiv, al cărei rol poate fi jucat de o mașină virtuală. 

Noile servicii dezvoltate pot fi compuse din serviciile Web deja existente, 
accesibile în mod transparent. Ne situám astfel la nivel de middleware, oferind atât 
funcționalități (implementate de codul-sursă al unor programe concepute în 
limbaje diverse), cât și suport pentru inter-operabilitate. 

Serverele Web actuale trebuie să funcţioneze ca porti spre pagini si servicii 
Web, deoarece încă există o bază largă de situri aliniate stilului ,vechi" (e.g., 
recurgând la scripturi CGI şi/sau servere de aplicaţii convenționale). 

Soluţia este oferită de implementarea și exploatarea unui cadru de lucru 
(framework) Web cu suport pentru SOA. Un astfel de cadru de lucru trebuie să 
asigure suportul pentru protocoalele Web si cele înrudite (HTTP, SMTP, FTP 
etc.), plus pentru familia XML. 


PREZENTARE GENERALA A SERVICIILOR WEB 35 


Ofertant/ utilizator de servicii Web ) 


E; 
E 
à 
E 
EM 


(server Web) 


Servicii de baza (calendar, tranzactii etc) j 
Contextul asociat serviciului (cine, de ce...) | 
Descrieri de servicii prin WSDL | 


| Protocoale Webs Internet aN SMTP stc) j 


Figura 4. Arhitectura stratificată a unui cadru de lucru 
aliniat problematicilor serviciilor Web 


De asemenea, trebuie să se pună la dispoziție mijloace pentru catalogarea, 
descoperirea si integrarea serviciilor Web via UDDI și descrierea funcționalități 
si intrărilor/ieşirilor gratie limbajului WSDL, cu posibilitatea generării automate 
de documente WSDL asociate serviciilor Web implementate. Suplimentar, dez- 
voltatorii vor putea recurge la facilități de specificare si atagare a unui context de 
execuție, luându-se în calcul factori precum autorizarea (cine poate invoca un 
anumit serviciu), localizarea (unde e localizat serviciul: platformă, server, port 
folosit si altele), planificarea (când poate fi rulat serviciul) etc. 

Pentru accesul la aplicații și sisteme tradiționale (/gacy) sau la servere de 
stocare (backend servers), cadrul de lucru va trebui să ofere un nivel de integrare. 
Mai mult decât atât, e necesară existența unui nivel de interfatare (frontend) via un 
server Web, care presupune existența unei/unor mașini virtuale și a unui motor 
de asigurare a fluxului de activități (workflow engine). La nivelul cel mai de sus se 
află ofertantul de servicii Web sau utilizatorul direct al acestora — vezi figura 4. 
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Actualmente există o sumedenie de tehnologii, produse si ofertanti de servicii 
Web, dintre care le enumerăm doar pe următoarele: Apache Axis implementat in 
Java, Borland Delphi/]Builder Web Services, IBM Web Services Toolkit, JBoss, Microsoft 
„NET Framework, NuSOAP şi PEAR::SOAP pentru PHP, modulul SOAP::Lite 
pentru Perl, Web Services Developer Pack pus la dispozitie de mediul Java. O parte 
dintre ele vor fi utilizate in cadrul exemplelor incluse in aceasta lucrare, in special 
în capitolul 6. De asemenea, există implementări oferite si de alte companii 
precum Apple, BEA, Fujitsu, Hewlett-Packard, Oracle, SAP, Sybase etc. 

Mai trebuie să remarcăm faptul că au apărut diversi ofertanti de servicii Web, 
dintre care îi enumerăm pe Amazon, Blogger, cddb (CD DataBase), eBay, European 
Bioinformatics Institute, Google, Interfax, LiveJournal, PayPal, RedHat, MSN (Virtual 
Earth), Shopsyne, Xignite şi Yaboo!. 

Drept direcţii importante de evoluţie se remarcă, pe de o parte, implementarile 
bazate pe Java si, pe de alta parte, serviciile Web bazate pe .NET Framework. 

La finalul acestui capitol notăm că unii specialiști considera că mediatizarea 
ştirilor (syndication) prin formatele deja notorii — RSS (Really Simple Syndication) şi 
Atom constituie tot o formă de acces la servicii Web. Astfel, informaţii diverse — 
marcate in RSS ori Atom și disponibile prin intermediul serviciilor de tip feed — 
pot fi integrate si prelucrate în diverse alte aplicaţii de sine stătătoare (BitTorrent, 
Excel sau iTunes) ori disponibile pe Web (eg, Gmail, Indeed.com, RSSW heather, 
TadaLzst, TagCloud, Technorati, Yahoo! Maps). 
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Capitolul 2 
Familia XML 


„Este mai bine să ştii câteva întrebări decât 
toate răspunsurile.” 


(James Thurber) 


1. Preliminarii 


Pentru identificarea resurselor, Web-ul recurge la identificatori uniformi de 
resurse (URI — Uniform Resource Identifiers), iar pentru interacțiune se foloseşte in 
mod uzual protocolul HTTP. Reprezentarea resurselor se realizeaza via formate 
de date. Arhitectura spaţiului WWW încurajează refolosirea formatelor existente, 
printre aspectele importante legate de acest latură putându-se enumera: adoptarea 
formatelor textuale în contrast cu cele binare, controlul versiunilor, extensibi- 
litatea, compunerea formatelor, separarea conţinutului, prezentării și interacțiunii. 

Cu proliferarea serviciilor Internet, mai ales ale Web-ului, datele au putut fi 
publicate liber, folosindu-se un format de redare (prezentare) a informaţiilor pus 
la dispoziţie de bine-cunoscutul HTML (HyperText Markup Language), în varianta 
actuală XHTML (Extensible HTML). În prezent, atenţia cade asupra modelării 
cât mai eficiente a informaţiilor, prin intermediul unui format deschis, 
extensibil — subiectul acestui capitol. Mai mult decât atât, modelarea datelor nu 
reflectă doar sintaxa (care e specificată printr-un set de convenţii de marcare), ci 
si semantica — până acum reprezentată de codul-sursă al programelor ce prelucrau 
acele date. 

Dacă formatele de date transpun maniera efectivă de stocare și prezentare a 
informaţiilor, la nivel conceptual trebuie adoptat cel puţin un model de repre- 
zentare. Evoluţia infrastructurilor de calcul a condus și la adoptarea unor modele 
de date diferite. 

Prezentul are la bază arhitecturile navigationale, bazate pe hipertext (text 
neliniar), utilizate de o pleiadă de dispozitive, inclusiv cele mobile. Se consideră 
că unul dintre modelele de date cele mai potrivite este cel oferit de familia de 
limbaje XML. 
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2. XML (Extensible Markup Language) 


Aproape de finalul secolului XX, Consorţiul Web a dorit crearea unui limbaj 
compatibil cu mai vechiul SGML (Standard Generalized Markup Language), dat care 
să se preteze la utilizarea in cadrul spaţiului WWW. În anul 1998, apare prima 
recomandare-specificatie privitoare la XML (Extensible Markup Language), iar la 
momentul scrierii acestei lucrări sunt în vigoare specificațiile XML 1.0 (ediţia a 
patra) si XML 1.1 (ediţia secundă). 


2.1. Caracterizare si trăsături esenţiale 


Putem considera XML ca reprezentând un standard internațional pentru descrie- 
rea de marcaje (markups) privitoare la resursele electronice. În fapt, XML reprezintă 
un meta-limbaj (descriere formală a unui limbaj, conform unei gramatici — suită 
de reguli prin care, pe baza unor simboluri, se generează cuvinte). La început, a 
fost văzut ca un limbaj de adnotare (de formatare) de texte, dar scopurile actuale 
depăşesc această interpretare îngustă. 

Termenul marcaj (markup) a fost utilizat initial pentru a descrie anumite 
adnotări, note marginale în cadrul unui text cu intenţia de a indica tehno- 
redactorului cum trebuie listat un anumit pasaj ori chiar omis. Cum formatarea 
și imprimarea textelor au fost automatizate, termenul s-a extins pentru a acoperi 
toate tipurile de coduri de marcare inserate în textele electronice cu scopul de a 
indica modul de formatare, listare ori alte acţiuni. 

Marcajul (codarea) reprezintă o acţiune de interpretare explicită a unui fragment 
de dată. Astfel, un Ambaj de specificare oferă un set de convenții de marcare utilizate pentru 
codificarea textelor. Un limbaj de marcare trebuie să desemneze mulțimea de 
marcaje obligatorii, permise, maniera de identificare a marcajelor și care este 
semantica fiecărui marcaj disponibil (similar procesului de specificare a sintaxei 
și semanticii unui limbaj de programare). 

Există următoarele caracteristici definitorii ale XML, primele trei fiind preluate 
de la SGML: utilizarea marcajelor descriptive (descriptive markups), adoptarea 
tipurilor de documente via DTD (Document Type Definition), independenţa datelor 
si caracterul case-sensitive (majusculele diferă de minuscule). 

Printre trăsăturile care au făcut meta-limbajul XML să fie folosit în industria 
software putem enumera: suportul acordat Web-ului, facilitățile pentru utilizarea 
internațională, meta-limbajul (se permite definirea de noi limbaje într-o manieră 
portabilă), soluţiile pentru reprezentarea conţinutului resurselor Web identificate 
via URI. 


FAMILIA XML 41 


Așadar, XML este o metodă de descriere universală a informaţiei, astfel încât 
atât computerele, cât mai ales oamenii să o poată înţelege. Scopurile limbajului 
sunt cele legate de utilizarea lui în Internet, suportând o varietate de aplicații, dar 
fiind mult mai flexibil decât HTML. Oferind o manieră universală pentru 
reprezentarea (descrierea) informaţiilor hipertext, XML poate fi văzut ca o 
tehnologie complementară limbajului HTML, nu ca o înlocuire a sa. 


2.2. Patti componente ale unui document XML 


Un document XML poate cuprinde următoarele categorii de constituenți: declaraţia, 
elementele, atributele, entităţile, secțiunile de marcare și instrucțiunile de procesare. 

Documentele XML pot să înceapă cu o declaraţie (prolog) XML care specifică 
versiunea limbajului XML utilizat — de exemplu: <?xml version="1.0" 
encoding="UTF-8" ?> (de asemenea, s-a precizat și tipul de codificare a setului 
de caractere folosit). 

Componenta structurală a unui document XML este ementul. Diferite tipuri 
de elemente au asociate nume diferite. Fiecare element trebuie specificat explicit 
prin intermediul marcajelor (Zag-urilor). Perechea marcaj de început (szart /ag)- 
-marcaj de sfârșit (end fag) este folosită la încadrarea fiecărei instante a elementului 
respectiv în cadrul unui text. În XML se utilizează «element» pentru a specifica 
un fag de început si </element> pentru cel de sfârșit, unde element este 
numele unui element oarecare (specificat de utilizator ori de autoritatea care a 
redactat specificaţiile limbajului bazat pe XML folosit). Regulile sintactice 
privitoare la numele de elemente sunt similare celor privitoare la identificatorii 
de variabile. Numele începând cu caracterele ,,xm/’ (in orice modalitate de 
scriere, cu majuscule sau minuscule) sunt rezervate. Numele de element nu 
poate conţine spaţii albe. 

Un element poate fi vid (nu contine nimic între /ag-urile de început si sfârșit), 
putând fi menţionat fie <element></element>, fie prin forma prescurtată 


«element />. De asemenea, poate include un text (sir de caractere) ori alte 
elemente. Mai multe elemente de același tip pot fi, așadar, imbricate. Un aspect 
deosebit de important este cel privitor la faptul că elementele trebuie să fie 
închise și imbricate corect. 

Conţinutul textual al unui element poate fi compus din caracterele permise de 
codificarea precizată de atributul encoding din declarația XML, orice apariţie de 
spaţii albe multiple fiind implicit redusă la un singur caracter spaţiu. 

Pentru a ilustra mai detaliat acest aspect, considerăm un model structural foarte 
simplu. Presupunem că dorim să identificăm o comandă de portocale ce va fi 
procesată de un sit de comerț electronic. Astfel avem: 
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<portocale> 
<!-- partea de achizitie de portocale --> 
<achizitii> 
<tip>Portocale greceşti fără coajă</tip> 
<cod>P10-01-GR</cod> 
<cantit um="kg">3374</cantit> 
</achizitii> 
<!-- partea de vânzări de portocale --> 
<vanzari> 
<tip>Portocale japoneze albastre</tip> 
<cod>P10-03-JP</cod> 
<cantit um="kg">0107</cantit> 
</vanzari> 
</portocale> 


Exemplul de mai sus nu ne precizează anumite reguli de compunere a 
comenzii (de exemplu, nu putem impune ca tipul produsului solicitat să nu apară 
de mai multe ori). Așadar, vom avem nevoie de un mecanism de specificare a 
structurii. 

Un atribut este utilizat cu scopul de a descrie o anumită proprietate a unei 
apariții specifice (particulare) a unui element. Atributele sunt localizate in zag-ul 
de start al unui element, imediat după numele elementului și sunt urmate de ,,=”, 
apoi de valoarea atributului scrisă între ghilimele sau apostrofuri. Dacă valoarea 
unui atribut nu este specificată între ghilimele, va fi semnalată o eroare, la fel ca 
și în cazul în care pentru un atribut nu ar fi atașată și valoarea acestuia. Pentru 
un element pot exista oricâte atribute, specificate în orice ordine, atât timp cât 
sunt declarate corect. 

Pentru exemplul dat mai sus, am specificat unitatea de măsură „kilogram” 
prin valoarea „kg” a atributului um asociat elementului <cantit>. 

Referințele la entităţi constituie de fapt pointeri către entităţi. În XML, 
entităţile reprezintă unităţi de text, unde o astfel de unitate poate desemna orice, 
de la un singur caracter la un întreg document sau chiar o referinţă la un alt 
document. O referință la o entitate prezintă construcţia sintactică &nume entitate; 


» 


(caracterul ,,&”, urmat de numele entității, apoi de caracterul ,,;”). Una dintre 
cele mai frecvente utilizări ale referintelor la entități este atunci cand se doreşte 
folosirea unor caractere care ar conduce la erori de procesare si deci care nu ar 
trebui să apară în forma lor normală în text (de exemplu, pentru a genera 
simbolul „<” vom folosi ,,&1t;”). În momentul în care se întâlnește referinţa la 
o entitate in document, aceasta se va substitui cu datele pe care le referă si se va 
returna documentul cu înlocuirile făcute. 

Ocazional, anumite parti ale documentului necesită un tratament special în 


ceea ce priveşte modul de procesare. Astfel, există posibilitatea folosirii secțiunii 
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CDATA (character data), cu rolul de inhibare a prelucrarii construcțiilor XML. 
Sectiunile CDATA pot fi inserate oriunde pot apărea datele de tip caracter. Ele 
sunt utilizate pentru a include blocuri de text conţinând caractere care altfel ar 
fi recunoscute ca marcaje. Acest aspect devine important atunci când documentul 
include, de exemplu, linii de cod-sursă scrise într-un limbaj de programare care 
are propriile convenţii sintactice. 
Sintaxa generală a secțiunii CDATA are forma «![CDATA[ ... ]]>. 
Sectiunile CDATA nu pot fi incluse unele în altele. 
Un exemplu este următorul: 
<achizitii> 
<tip>Portocale greceşti fără coajă</tip> 
<obs><! [CDATA[ 
Cantitatea trebuie să fie >2000. 


]]></obs> 
</achizitii> 


Instrucţiunile de procesare reprezintă un tip special de marcaj care conţine 
informaţii privitoare la anumite aplicaţii ce urmează a fi executate pentru 
procesarea conținutului. Un exemplu este instrucțiunea de procesare care permite 
atașarea de foi de stiluri documentelor XML în vederea redării conţinutului 


acestora: 


| <?xml-stylesheet href="xml2html.xsl" type="text/xsl" ?> 


2.3. Membrii constituenți ai familiei XML 


Limbajul XML oferă mai mult decât o sintaxă comodă pentru reprezentarea 
datelor structurate sau semistructurate. XML consistă dintr-o familie de limbaje 
bazate pe XML pentru reprezentarea datelor si relațiilor dintre ele. 

Această familie de limbaje, menite a adapta conceptele curente de stocare, 
modelare și publicare pe Web a datelor, este compusă din: 


* XML (Extensible Markup Language) — subset al specificaţiei SGML, conceput 
pentru o implementare mai usoara. Modalitatile de validare sunt concretizate, 
uzual, de schemele XML, complementare DTD-urilor; 

* XLL (Extensible Linking Language) — oferind suport pentru specificarea de 
legături hipertext, concretizat în două componente majore: 

— XLink — conceput pentru descrierea legăturilor (simple sau multiple) 
dintre resursele Web; 

— XPointer — are ca scop precizarea în manieră extensibilă a unor scheme de 
adresare a datelor XML; 
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e XSL (Extensible Stylesheet Language) — permite transformarea documentelor 
XML în alte tipuri de documente (XML, XHTML sau altele) si atașarea unor 
obiecte de formatare, în vederea redării conţinutului XML în formate precum 
PDF (Portable Document Format); 

e XQuery — împreună cu limbajul XPath, oferă posibilitatea interogárii docu- 
mentelor XML. 


Practic, este imposibil să se enumere toate limbajele bazate pe XML existente 
la ota actuală, standardizate sau nu. Numeroase limbaje utile, in număr de peste 
500, sunt descrise la adresa ///p:/ / xzul.coverbages.org/ . 


2.4. Spațiile de nume XML 


In unele situatii pot apárea confuzii, atunci cánd se folosesc date din diverse 
surse (documente) XML care pot avea elemente/atribute cu același nume, dar cu 
semnificaţii (semantici) diferite. Pentru evitarea acestor ambiguitati sunt folosite 
spaţiile de nume, astfel încât numele de elemente și/sau atribute vor fi identificate 
în mod unic, evitându-se conflictele. 

Necesitatea folosirii spaţiilor de nume se poate remarca din exemplul următor, 
în care considerăm două documente XML, primul cu informaţii despre partenerii 
de afaceri, al doilea despre numele furnizorilor de portocale: 


<!-- parteneri de afaceri > 
<parteneri> 
<partener> 
<nume>Portocal Escu</nume> 


<adresa>Aleea Zăpezilor, 33</adresa> 
</partener> 


</parteneri> 


«lee fuüurnizora ==> 
<furnizori> 
<furnizor adresa="http://ja.po.ro/"> 
<nume>Japo Nez S.A.</nume> 
</furnizor> 


</furnizori> 
Documentul care le utilizeaza pe precedentele si foloseste spatii de nume 


pentru evitarea ambiguitatilor („nume reprezintă un nume de persoană sau un 
nume de companie?”; ¿dem pentru adresă) ar putea fi următorul: 
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<comanda xmlns:p="http://www.undeva.ro/parteneri/"> 
<partener> 
<p:nume>Portocal Escu</p:nume> 


<p:adresa>Aleea Zăpezilor, 33</p:adresa> 
</partener> 
<f:furnizor xmlns:f-"urn:furnizori.info" 
f:adresa-"http://ja.po.ro/"» 
<nume>Japo Nez S.A.</nume> 
«/f:furnizor» 


</comanda> 


Atributul xmins este folosit pentru declararea spatiilor de nume, iar valoarea 
lui trebuie să fie un URI, fie localizând o resursă prin adresa ei — cazul URL 
(Uniform Resource Locator), fie desemnând un nume unic asociat resursei în cauză — 
facilitate oferită de URN (Uniform Resource Name). Prin intermediul construcţiei 
xmlns, se asociază un vocabular, denumit si spafin de nume (namespace), pentru 
elementele în cauză. 


2.5. XML Infoset 


XML nu trebuie considerat a fi doar o manieră de precizare la nivel sintactic a 
structurii și conţinutului unor resurse. Mai mult decât atât, Consorţiul Web a pus 
problema redactării unei recomandări care să specifice un model de date (abstract) 
pentru XML, numită XML Information Set (saa XML Infoset). 

Prin intermediul acestei specificaţii se oferă un punct de vedere comun 
referitor la: serializarea datelor semistructurate, implementarea/ folosirea de 
interfețe de programare (API-uri) pentru procesarea XML, definirea unor alte 
recomandări de nivel (mai) înalt. 

Acest model de date asigură inter-operabilitatea diferitelor tehnologii, interfeţe 
de programare și aplicaţii XML, stabilind o interpretare comună a conceptelor 
folosite. 

Sunt definite următoarele concepte de bază, împărtășite de întreaga familie 


XML: 


— document (document information item) — este considerat a fi un arbore, având nodul 
rădăcină dat de proprietatea [document element]. De asemenea, posedă 
proprietatea [children] oferind o serie de „lucruri” de interes (//ez25); 

— element — specifică un element XML şi are ataşată proprietatea [parent] 
conținând informaţii despre elementul părinte căruia îi aparține. Are asociată 
și proprietatea [children] cu semantica descrisă mai sus. Proprietatea 
[local name] specifică numele local al elementului al cărui scop (vizibilitate) 
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e dat(ă) de proprietatea [namespace uri] indicând URI-ul spaţiului de 
nume folosit (vid, dacă nu se specifică spaţii de nume). Prefixul spaţiului de 
nume utilizat este stocat de proprietatea [prefix]. Astfel, se dă posibilitatea 
precizării calificate a numelor elementelor. Accesul la lista neordonată a 
atributelor asociate elementului se face via proprietatea [attributes]. De 
asemenea, proprietatea [namespace attributes] menționează lista neor- 
donată a atributelor xmlns ataşate; 

atribut (attribute) — desemnează conceptul de atribut XML. Numele și spaţiul 
de nume atașat sunt specificate de proprietăţile [local name] și 
[namespace name]. Elementul căruia îi aparţine este indicat de proprietatea 
[owner element], iar valoarea e specificată de [normalized value] 
(valoarea normalizata, rezultata dupa expandarea tuturor referintelor la 
entități); 

caractere (characters) — corespund informaţiilor textuale ale conţinuturilor ele- 
mentelor XML. Proprietatea [parent] indică elementul căruia îi aparţin, iar 
[children] conţine datele-caracter propriu-zise. Setul de caractere utilizat e 
oferit de proprietatea [character code]. 


Prin intermediul XML Infoset, datele XML nu trebuie neapărat să aibă 


reprezentări textuale, stocate în fişiere .x77/, ci pot proveni din diverse alte surse 


(obiecte, rezultate ale unor interogări etc.), cu reprezentări diferite. Intuitiv, 


structura unui document XML complex poate fi mult mai ușor înţeleasă având 


asociată o reprezentare grafică arborescentă — a se vedea figura 1. 


[ ]portocale 
5- @ achizitii 
MET tip Portocale grecesti Fara coaja 
P @ cod P10-01-GR 
a «o I[CDATA[ Cantitatea trebuie 


[DO c € cantit "kg 
5- 9 vanzari 
© tip Portocale japoneze albastre 
-@ cod P10-03-JP 
@ cantit "kg" 0107 


Figura 1. Reprezentarea arborescentă 
a unui document XML 
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2.6. Validarea documentelor XML 


Punerea problemei 


O primă necesitate in cazul adoptării tehnologiei XML este aceea ca informaţiile 

marcate în XML să poată fi regăsite, reutilizate și partajate între diverse aplicații. 

Astfel, o cerință importantă este de a cunoaște: 

— setul de elemente/atribute ce pot fi specificate; 

— modul lor de structurare (eg, ordinea, numărul minim/maxim de apariţii, 
contextul etc.); 

— tipul conţinutului (de exemplu, cantitatea de portocale să reprezinte un 
număr natural, aparţinând intervalului [0, 7433]); 

— ce anume este valid si ce reprezintă eroare. 


Soluţia este ca un grup sau grupuri de indivizi (precum o companie, o 
industrie, persoane, producători de instrumente software specifice sau un 
consorțiu) să specifice mulțimea de elemente și atribute permise și regulile de 
marcare, adică tocmai modelul structural amintit mai sus. 

Modelul structural se aplică unei clase de documente XML, în vederea 
verificării printr-un analizor (numit și procesor sau parser) a corectitudinii 
instanţelor de documente aparținând acelei clase. Se au în vedere aspecte privind: 


— modul de numire a elementelor/atributelor; 
— definirea regulilor de utilizare a acestora; 

— specificarea structurii și conținutului; 

— precizarea anumitor constrângeri; 

— oferirea unui set de convenţii de numire. 


Apare așadar necesitatea specificării unui set de constrângeri asociate docu- 
mentelor, astfel încât datele XML să fie verificate dacă sunt valide sau nu din 
punct de vedere structural sau al tipului conţinutului. 

Modalitátile de precizare a constrângerilor se pot baza pe: descrieri (DID și 
XML Schema), reguli (Sablotron) şi sabloane (RELAX NG) — detalii în cartea lui 
Sabin Buraga, Tehnologii XML, Polirom, Iasi, 2006. 
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Descriere succintă a XML Schema 
* Caracteristici 


Deoarece este una dintre cele mai utilizate și versatile maniere de validare a 
documentelor XML, în cele ce urmează vom prezenta cele mai importante 
aspecte referitoare la XML Schema, recomandarea oficială a Consortiului Web. 

O schemă reprezintă o specificaţie formali a gramaticii asociate 
unui document XML și reprezintă, în fapt, tot un document XML stocat într-un 
fişier având extensia .xsd (XML Schema Definition). O schema XML defineşte o 
Clasă de documente XML conformându-se unui model structural suplimentar, 
specificând un sistem de tipuri de date în termenii /pfoser-ului (vezi supra). Pentru 
a putea fi verificată validitatea, o instanță a unei clase de documente XML 
trebuie să aibă asociată o schemă XML. Aceste aspecte sunt asemănătoare celor 
de la paradigma obiectuală. 

O schemă va specifica modul de apariţie și tipurile de date pe care le pot lua 
valorile construcţiilor XML. Rezultatul obţinut în urma unei validări încununate 
cu succes este numit și PSVI (Post-Schema Validation Infose?). 

Schemele XML sunt utilizate in multe domenii, dintre care le enumerám pe 


următoarele: 


— verificarea tipurilor de date în contextul sistemelor de baze de date (relationale) 
a mașinilor virtuale (CLR, JVM) etc.; 

— setializatea automata a datelor; 

— invocarea la distanță a metodelor (RMI — Remote Method Invocation, SOAP — 
Simple Object Access Protocol) — a se vedea cele discutate în capitolul 4; 

— generarea de cod-sursă; 

— implementarea de editoare „inteligente”; 

— crearea validatoarelor generale de date (e.g., validarea formularelor electronice). 


Construcţiile XML Schema trebuie să aparțină spaţiului de nume indicat de 
adresa hitp://www.w3.org/2001/XMLSchema. Atributele privitoare la scheme ce 
apar in cadrul unei instante a unei clase de documente vor proveni din spatiul 
de nume specificat de //p:/ / mwm.w3.org/ 2001 / XM LSchema-instance. 


* Constructii de bazá 


Un document XML Schema ate ca element-rădăcină «xsd:schema». Definirea 
sau instantierea unui element se realizează via «xsd: element», iar în cazul unui 
atribut prin «xsd:attribute». 
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Asemănător definirii unor tipuri de date și variabile într-un limbaj de 
programare, într-o schema XML fiecare instanță de element trebuie 
să aparțină unei clase (tip) de elemente. Un element/atribut va avea valori 
permise ce aparţin unui tip de date (simplu sau complex), specificat prin 
<xsd:SimpleType> si, respectiv, <xsd:ComplexType>. 

Tipurile simple, predefinite ori derivate din cele predefinite, descriu conţinutul 
datelor textuale. În acest caz, nu se permite ca un element să includă alte 
elemente și nici să aibă asociate atribute. Tipurile simple pot fi folosite și pentru 
specificarea conţinutului atributelor. 

Tipurile complexe descriu datele (semi)structurate. În acest caz, se acceptă ca 
elementele să includă alte elemente (prin reguli de apariţie) si să aibă asociate 
atribute. Elementele de tip complex vor putea conţine: 


— declarații de elemente, prin intermediul construcţiei <element name="nume" 
type="tip" />; 


— referinte la elemente a priori definite: « lement ref-"nume" reguli aparitie- 


"valori" />; 


— declaratii de atribute via «attribute name-"nume" type-"tip" /». 


Tipurile complexe nu pot fi folosite in contextul stabilirii tipului valorilor 
atributelor XML. 

Consorţiul Web a pus la dispoziţie o paletă largă de tipuri predefinite (primite 
si derivate). Cele mai utilizate sunt enumerate în continuare: 


— numerice: byte, unsignedByte, integer, positivelnteger, negativeInteger, 
int, long, decimal, float, double si altele; 

— logice: boolean; 

— privitoare la dată si timp: time, dateTime, duration, date, gYear, gMonth, 
gDay etc.; 

— şiruri de caractere: string, token si altele; 

— adrese Web: anyURI. 


Ierarhia tipurilor de date XML Schema este ilustrată de figura 2. 

Pentru codificari ale continuturilor binare in cadrul documentelor XML se 
poate folosi tipul base64Binary, care oferă o reprezentare a oricăror şiruri de 
octeți prin intermediul a 65 de caractere specificate de documentul RFC 2045. 
Mulțimea acestor caractere e compusă din literele minuscule și majuscule, cifre, 
diverse simboluri și caracterele desemnând spaţiile albe. 
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anyType 
i 
*-4 toate tipurile complexe 
anySimpleType 
normalizedString | token | 


[e ] eroe] ser] nes | 
ETE RENTE 
Les] Lo Hoe He 
zw ] Howe 

ETE 


LL tipuri generice =~ derivate prin restricţie 
[CI tipuri primitive predefinite — «^ derivate via liste 


[O tipuri derivate predefinite derivate prin extensie 
CI tipuri complexe sau restricție 


Figura 2. Tipurile de date specificate de XML Schema 


Putem defini tipuri simple derivate din cele predefinite via <xsd: simpleType>. 
Noul tip de date specificat poate fi o restricție a unui tip deja existent prin 
intermediul unor constrângeri (facets). Prin intermediul constrângerilor pot fi 
precizate aspecte precum: 


— lungimea: <xsd:length>; 

— lungimea minimă: <xsd:minLength>; 

— lungimea maximă: «xsd:maxLength»; 

— un model (pattern), exprimat printr-o expresie regulată: <xsd:pattern>. 


De asemenea, putem recurge la precizarea unei liste de valori (folosind 
<xsd:enumeration>) ce va forma tipul sau a unui interval de valori (construcțiile 


<xsd:minInclusive>, «xsd:maxInclusive», <xsd:minExclusive> si 


<xsd:maxExclusive>). 

Tipurile simple noi vor fi folosite să descrie valorile elementelor/atributelor, 
atasarea acestora unor construcții XML putând avea loc fie în cadrul schemei la 
declararea unui element, fie în cadrul instanţei via atributul xsi : type. 
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» 


De asemenea, vom putea preciza următoarele (simbolul ,,|” semnifică o 


alternativă): 


— reguli (restricţii) de apariţie a unei instante de element: numărul minim de 
apariții (minOccurs="num&r") şi/sau numărul maxim de apariții (maxOccurs= 
"număr | unbounded"); 

— reguli de apariţie a unui atribut (obligatoriu, opţional sau interzis): use= 
"required | optional | prohibited"; 

— valoarea predefinita a unui atribut via default; 

— valori particulare pentru elemente sau atribute: fixed. 


De reţinut că tipurile simple pot fi utilizate doar pentru a descrie date-caracter. 
În vederea definirii structurii unui document se recurge la «xsd:complexType». 
Un tip complex poate avea un conținut simplu (<xsd:simpleContent>) sau 
unul complex. 

Conţinutul simplu înseamnă că un element va putea include atribute, extinzând 
astfel modelul-continut. O prima metodă este derivarea prin extensie, via 
elementul <xsd:extension>, iar a doua modalitate vizează derivarea prin 
restricție, realizată prin intermediul constrângerilor (facets). Atributele vor fi 
definite prin intermediul <xsd:attribute>, putând fi declarate global (la nivelul 
schemei) sau local (în cadrul unui tip complex). De asemenea, ele pot fi calificate 
(prefixate de spaţiul de nume ales) sau nu. 

Specificarea unui tip cu conţinut complex vizează definirea listei și ordinii 
sub-elementelor și atributelor sale. Conţinutul unui element poate fi și mixt 
(compus din sub-elemente sau date-caracter): «xsd: complexType mixed="true"> 


oti vid (nu va contine decat declaratii de atribute). 
Pentru a preciza diverse modele ale continutului, vom adopta constructii 
referitoare la: 


alternativa: <xsd:choice>; 

— secventa: <xsd:sequence>; 

— grupare: <xsd:group>; 

— apariție a tuturor elementelor, în orice ordine: <xsd:a11>. 


De menţionat si faptul că specificarea unor elemente/atribute generice (ale 
altor tipuri de documente) se realizează prin elementele <xsd:any> și <xsd: 
anyAttribute>. De asemenea, XML Schema oferă şi suport pentru documentare 
via <xsd:annotation>. 

În continuare vom furniza un exemplu de schemă XML menită a valida 
documentul privitor la achiziţiile si vânzările de portocale, menţionat în secțiunea 
2.2 a capitolului de fata. Structura schemei este următoarea: 
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<xsd:schema 
xmlns:xsde"http://www.w3.org/2001/XMLSchema" 
xmlns-"urn:portocale.info" 
targetNamespace-"urn:portocale.info"» 
<xsd:annotation> 
<xsd:documentation xml:lang="ro"> 
O schemă utilizată la validarea 
tranzacţiilor de portocale 
</xsd:documentation> 
</xsd:annotation> 


<!-- definirea elementului-rádáciná "portocale" --> 


<xsd:element name-"portocale" type-"portocaleType" 
<xsd:complexType name="portocaleType"> 
<!-- o secvență de alternative ==> 
<xsd:sequence maxOccurs="unbounded"> 
<xsd:choice> 


<!-- măcar o aparit. a elem. "achizitii" 
<xsd:element name-"achizitii" 
type="prodType" 
minOccurs-"1" maxOccurs-"unbounded" 
<!-- idem si pt. "vanzari" ==> 
<xsd:element name="vanzari" 
type-"prodType" 
minOccurs-"1" maxOccurs-"unbounded" 
«/xsd:choice» 
<xsd:sequence> 
«/xsd:complexType» 


<!-- tipul complex "prodType", 
folosit pentru achiziţii sau vânzări --> 
«xsd:complexType name="prodType"> 
<xsd:sequence> 
<xsd:element name-"tip" type-"xsd:string" 
minOccurs="1" maxOccurs="1" /» 
<xsd:element name="cod" type="xsd:string" 
minOccurs="1" maxOccurs="1" /> 
<!-- elementul "obs" e optional --> 
<xsd:element name="obs" type="xsd:string" 
minOccurs="0" maxOccurs="1" /> 
<xsd:element name="cantit"> 
<xsd:complexType> 


<!-- derivam dintr-un tip simplu --> 
<xsd:simpleContent> 


/> 


J> 


/> 


<xsd:extension base="xsd:unsignedInt"> 
<!-- specif. aparitia (obligatorie) 


a atributului "um" ==> 
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<xsd:attribute name="um" 
type="xsd:string" 
use="required" /> 
</xsd:extension> 
</xsd:simpleContent> 
</xsd:complexType> 
</xsd:element> 
</xsd:sequence> 
<!-- un identificator optional --> 
«xsd:attribute name="id" type-2"xsd:ID" 
use-"optional" /» 
</xsd:complexType> 
</xsd:schema> 


Reprezentarea grafică a schemei e disponibilă în figura de mai jos. 


portocaleType prodType 
portocale achizitii 


um:portocale. info 


1,,00 


Figura 3. Reprezentarea generată de editorul <oXygen / > a schemei XML. 


Mai urmează să utilizăm schema de mai sus pentru a verifica validitatea unei 
instanţe de document XML care trebuie să declare un spaţiu de nume cu un URI 
desemnând schema utilizată. 

La nivelul unei instanţe de document vom folosi o construcție de genul: 


<portocale xmlns="urn:portocale.info" 
xmlns:xsi- 
"http://www.w3.0rg/2001/XMLSchema-instance" 
xsi:schemaLocation- 
"urn:portocale.info file:portocale.xsd"» 
<!-- conținut propriu-zis ==> 
</portocale> 
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Aplicația «oXygen /> XML Editor amintită mai sus poate fi folosită si ca 
validator de documente XML. 

În cele de mai jos ilustrăm anumite mesaje de eroare afișate de unul dintre 
utilitarele puse la dispoziţie de procesorul Apache Xerces — disponibil în regim open 
source — în cazul unui document XML invalid, conform schemei descrise anterior: 


P:\xerces>DOMPrint.exe -v=always -n -s -f portocale.xml 


Error at file "portocale.xml", line 7, column 21 

Message: Unknown element 'suplimentar' 
Error at file "portocale.xml", line 11, column 21 

Message: In element cod: Can not have element children 
within a simple type content 
Error at file "portocale.xml", line 12, column 14 

Message: Required attribute 'um' was not provided 
Error at file "portocale.xml", line 13, column 15 

Message: Element 'suplimentar' is not valid for content 
model: '((tip,cod,obs),cantit)' 


Un rezultat aproape similar obtinem utilizand Microsoft Visual Web Developer 
pentru editarea si validarea documentelor XML — a se urmări figura alăturată. 


portocale.xml| portocale ssd | 
<?xml version-"1.0" encoding-"UTF-8" ?> 
<portocale xmlns="urn:portocale. info" 
xmlns:xsi="http://wuw.w3.org/2001/ XHLSchema-instance” 
B xsi:schemaLocation-"urn:portocale.info portocale.xsd"- 
d «achizitii xmlns=""> 
<tip>Portocale grecesti fara coaja</tip> 
<guplimental| ¿> 
E “The element 'achizitii' has invalid child element 'suplimentar'. List of possible elements expected: 'cod'. 
E <obs>. . .</cod> 
<cantit>3374</cantit> 
F <f/achizitii> m 
BE <vanzari xmlns-"'... 
- X«/portocale- 


Figura 4. Semnalarea erorilor de validare a unui document XML în cadrul instrumentului 
Visual Web Developer 


2.7. Procesarea documentelor XML 


Modelul DOM 


Consorţiul Web a propus pentru prelucrarea sofisticată a documentelor XML 
şi/sau HTML un model obiectual denumit DOM (Document Object Model). Acest 
model reprezintă o interfață de programare a aplicaţiilor destinate să prelucreze 
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documentele HTML si XML, independenta de platforma si de limbaj, definind 
structura logică a documentelor și modalităţile de accesare si de modificare a lor. 

Structura logică a documentelor este o structură arborescentă, conformă cu 
XML Infoset, documentele fiind modelate utilizând obiecte, iar modelul nu 
furnizează doar o vizualizare structurată a documentului, ci și o modalitate de 
specificare a comportamentului lui și a obiectelor componente. Fiecare element 
al unui document poate fi privit, aşadar, ca un obiect cu o identitate și o serie 
de funcţii proprii. 

Recomandările DOM sunt structurate pe mai multe nivele de specificare a 
modelului. Nivelul 0 (pentru HTML) a fost nivelul de funcţionalitate a versiunilor 
3 ale navigatoarelor Netscape și Internet Explorer. Nivelul 1 este recomandarea 
standardizată din anul 1998, iar în 2000 a fost standardizat DOM — nivelul 2. 
Partial, nivelul 3 al DOM a fost publicat ca recomandare oficială în anul 2004 
si este in curs de standardizare completă. 

DOM nu este o specificaţie binară și nu definește nici o formă de inter-ope- 
rabilitate la nivel binar, in contrast cu alte tehnologii, precum CORBA (Common 
Object Request Broker Architecture) ori COM (Common Object Model). DOM reprezintă 
un model care specifica interfete si nu este un set de structuri de date (abstracte). 
De asemenea, nu defineste semantica detaliata a documentelor HTML sau XML. 

Specificatia DOM reprezinta documentele ca o ierarhie de obiecte-nod. 
Anumite tipuri de noduri pot avea noduri copii (descendenti) de diverse tipuri. 
Altele pot fi noduri frunza, lipsite de descendenti. Tipurile fundamentale de 
noduri sunt cele din următorul tabel: 


Tip Descendenti 
Document Element, 
ProcessingInstruction, 
Comment, 
DocumentType 


DocumentFragment Element, 
ProcessingInstruction, 
Comment, 

Text, 

CDATASection, 
EntityReference 


DocumentType - 


EntityReference Element, 
ProcessingInstruction, 
Comment, 

Text, 

CDATASection, 
EntityReference 


56 SERVICII WEB 


Descendenti 


Element Element, 

Text, 

Comment, 
ProcessingInstruction, 


CDATASection, 
EntityReference 

Attr Text, 
EntityReference 

ProcessingInstruction - 

Comment - 

Text - 

CDATASection - 

Notation - 

Entity Element, 
ProcessingInstruction, 
Comment, 
Text, 
CDATASection, 
EntityReference 


Pentru fiecare tip de nod, DOM oferă o interfaţă care desemnează constantele, 
variabilele și metodele ce vor putea fi folosite de programator într-o imple- 
mentare efectivă a modelului. Există o serie de interfeţe fundamentale (e.g., 
Document, DocumentFragment, Node, NodeList sau Aitr), plus diverse interfeţe extinse 
pentru a suporta implementări având în vedere procesarea documentelor HTML 
ori oferind facilități adiționale. 

În continuare, vom descrie succint o serie dintre interfețele puse la 
dispoziţie. 

O interfață importantă este DocumentFragment care poate reprezenta un obiect- 
-document minimal. Sunt numeroase situaţiile în care nu trebuie lucrat cu 
întregul document, ci doar cu diverse fragmente ale sale. Arborele de noduri al 
unui fragment de document este un sub-arbore al structurii de noduri a 
documentului luat în întregul lui. În funcţie de necesităţi, DocumentFragment poate 
reprezenta o entitate XML, un element XML sau chiar un grup de elemente. 

Interfața Document reprezintă un document XML, desemnând conceptual 
rădăcina arborelui de noduri-obiecte ale documentului și oferind accesul la 
informaţiile conţinute de acesta. Din moment ce elementele (marcatorii), nodurile 
de tip text, comentariile, instrucţiunile de procesare nu pot exista în afara 
contextului unui document, interfața Document conţine de asemenea metodele 
necesare pentru a crea aceste categorii de obiecte. 
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lii. 


Interfata Document are ca membri trei atribute: 


doctype reprezintă declaraţia tipului de document (DTD) asociată unui 
document particular. 

implementation specifică implementarea sau implementările disponibile 
pentru procesarea documentului. 


documentElement (de tip E/emen?) desemnează nodul-rădăcină de accesare a 
structurii arborescente a documentului. 


Menţionăm următoarele metode importante: 


createElement() creează un element XML; 


createTextNode (), createComment (), createCDATASection(), create- 


ProcessingInstruction() vor genera noduri-obiect de tip text, comentariu, 
sectiune CDATA, respectiv instructiune de procesare; 

createAttribute () creează un obiect atribut care va fi asociat unui element 
specificat; 


getElementById() va întoarce elementul al cărui atribut zd se potrivește cu 
cel furnizat ca argument al acestei metode (în acest mod poate fi selectat 
exact un anumit element, știind că identificatorul asociat trebuie să fie unic); 


getElementsByTagName() va returna o listă ordonată de noduri Nodel zs 
pentru toate elementele corespunzătoare unui /ag, ordonarea nodurilor reali- 
zându-se prin parcurgerea în preordine a arborelui; 


Interfața Node definește un tip primar pentru întregul model DOM, repre- 


zentând un anumit nod în cadrul arborelui asociat unui document. Atributele 


nodeName, nodevalue şi attributes sunt introduse ca mecanisme pentru 


furnizarea informaţiilor despre noduri fără conversie de tipuri (vizualizare 


„simplificată”, nu una „orientată-obiect”). Fiecare nod va avea asociată o listă 


ordonată conținând descendenţii săi, plus atribute specificând nodul părinte, 


primul si ultimul nod copil, dacă există. 


Ca metode prezentând interes se pot menţiona cele care manipulează nodurile 


copil: 


insertBefore () permite inserarea unui nod înaintea celui curent; 
replaceChild() substituie un nod-copil; 

removeChild() elimina un nod-copil specificat; 

appendChild() adaugă un alt nod-copil; 

cloneChild()cloneazá un anumit nod-copil; 

hasChildNodes ()intoarce “we dacă există noduri-copil; 

hasAttributes () întoarce “we daca nodul are atribute (metodă introdusă in 
DOM nivelul 2); 
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e isSameNode () întoarce “we dacă nodul curent e identic cu un altul specificat 
(metodă oferită de DOM nivelul 3). 


NodeList reprezintă o interfaţă care oferă un tip abstract de dată pentru 
colecţiile ordonate de noduri, fără a defini sau restricționa cum va fi implementată 
efectiv această colecţie. Fiecare implementator va decide ce tipuri de date 
concrete vor fi utilizate. Membrii colecției se vor accesa prin metoda item ()pe 
baza unui index întreg, numerotarea nodurilor începând cu valoarea 0. 

Interfața NamedNodeMap este folosită pentru reprezentarea abstractă a colec- 
tilor neordonate de noduri, prelucrate prin intermediul numelui. Interfața 
NamedNodeMap nu derivă din NodeList. 

Interfața Afr modelează un atribut din cadrul unui obiect de tip Element. 
Tipic, valorile permise ale atributelor sunt definite in schema XML cores- 
punzatoare documentului. Un obiect Avr nu se consideră că aparţine arborelui 
de noduri-obiect al documentului. Nodurile de tip A#r sunt considerate pro- 
prietati ale elementelor (marcatorilor), putând fi asociate nodurilor Element 
conţinute de obiecte de tip DocumentFragment. 

Interfața E/ezent derivă din Node si oferă metode de accesare a obiectelor 
"ttr, prin nume sau prin valoare: getAttribute (), setAttribute (), remove- 
Attribute (), getAttributeNode (), setAttributeNode (), removeAttribute- 
Node (). 

Interfața Text este o interfaţă reprezentând conţinutul textual (date de tip 


șiruri de caractere) al unui nod Element sau Afr. Dacă între /ag-urile de început 
și de sfârșit nu există alți marcatori, atunci textul va fi stocat într-un obiect 
implementând interfața Tex. 

În prezent există implementări complete pentru DOM — nivelurile 1 si 2 — în 
majoritatea limbajelor de programare actuale (C/C++, CH, Java, JavaScript, 
Perl, Python etc.). Drept exemple notabile de biblioteci si interfeţe de programare 
disponibile în diverse limbaje pot fi enumerate J ASP (Java API for XML Parsing), 
JDOM, libxml, MSXML.NET, ODOM, Xerces DOM API şi XML::DOM. 

O serie de exemple de manipulare prin DOM a documentelor XML, pentru 
procesarea răspunsurilor obținute de la serviciile Web invocate sau în contextul 
AJAX, sunt furnizate în cadrul capitolului 6. 


Procesarea XML prin SAX 


Pentru documente de dimensiuni mari, modelul DOM este ineficient, deoarece 
înainte de a se realiza prelucrarea, documentul respectiv trebuie încărcat complet 
în memorie. Ca alternativă la implementările DOM, există o interfață simplă de 
programare destinată manipulării documentelor XML, însă nu atât de completă 
precum DOM. Această interfață este denumită SAX (Simple API for XML). 
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Majoritatea celor care se ocupa de prelucrarea documentelor XML vad 
structura unui document în formă arborescentă, iar modelul DOM oferă din plin 
posibilitatea de a manipula informaţiile în această manieră. Din punctul de 
vedere al implementatorilor această abordare are numeroase deficienţe (maniera 
de stocare internă a arborelui de obiecte, parcurgerea lui etc.). Unul dintre 
beneficiile utilizării interfeței SAX este că arborele nu mai trebuie construit, 
dându-i-se programatorului o altă cale de analiză a documentului XML. Mai 
mult, SAX poate ajuta la convertirea datelor din formatul arborescent DOM în 
alt format mai comod, iar pentru procesare nu este necesar a se memora întreaga 
informatie XML, ci numai părțile dorite. 

Detalii privitoare la SAX si alte maniere de procesare XML sunt oferite de 
resursele bibliografice indicate. 


Analizoare XML 


Desigur, pentru prelucrarea documentelor XML va trebui să recurgem la un 
analizor XML deja implementat în limbajul nostru preferat. Analizoarele XML 
pot fi de două tipuri: 


— analizoare fără validare, cate vor procesa un document XML verificand daca 
acesta este bine formatat (adică respectă regulile privind sintaxa și modul de 
imbricare corectă a /ag-urilor); 

— analizoare cu validare, cate vor realiza procesarea documentului XML prin 
verificarea regulilor formale descrise de un DTD sau o schemă atașate 
acestuia (aceste analizoare sunt mai complexe). 


Unul dintre cele mai cunoscute analizoare fără validare este Expat, disponibil 
în regim open source. De asemenea, pot fi utilizate analizoarele cu posibilități de 
validare [AXP (Sun), JDOM, äbxmi (parte a proiectului GNOME), MSXML 
(Microsoft) sau Xerces (Apache). Practic toate mediile de dezvoltare Web actuale 
oferă posibilități de validare a documentelor XML via DID sau XML Schema 
si diverse modalități de procesare. 
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1. 


Capitolul 3 


Descrierea serviciilor Web 


„Analfabetul viitorului nu va mai fi cel care nu ştie 
să citească; va fi cel care nu ştie să înțeleagă.” 


(Alvin Toffler) 


Punerea problemei 


Aşa cum am menţionat în primul capitol, modul de acces la un serviciu Web este 


specificat printr-un set de documente care conţin definiţii, toate acestea consti- 


tuind descrierea serviciului. 


Asemenea documente pot fi văzute drept blocuri menite a furniza descrierea 


unui serviciu Web, incluzând (a se urmări si figura 1): 


definiția unui serviciu = abstractă + concretă (service definition = abstract + 
concrete); 

descrierea unui serviciu = definiția serviciului + definiții suplimentare (service 
description = service definition + supplementary definitions). 


Să analizăm fiecare dintre termenii de mai sus: 


descrierea interfeței unui serviciu Web este independentă de implementare si 
este referită de termenul „abstract”. Informațiile despre implementarea si 
localizarea serviciului Web constituie părți „concrete” ale documentului care 
descrie serviciul. Termenii „abstract” si „concret” au fost introdusi cu sensul 
de mai sus de către Consortiul Web în specificațiile privind arhitectura 
serviciilor; 

definiția serviciului (service definition) este compusă din definițiile interfeței 
(abstracte) si definițiile implementării (concrete); 

descrierea unui serviciu (service description) constă de obicei doar din definiția 
serviciului, însă — opțional — ea mai poate conține informații suplimentare (de 
exemplu, cum este conectat serviciul respectiv de alte servicii). 
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Descriere abstracta 
(definitie a interfetei 
serviciului) 


Descriere concreta 
(definitie 
a implementarii 
serviciul 


Descrierea serviciului 


Figura 1. Confinutul descrierii unui serviciu 


2. WSDL (Web Service Description Language) 


Serviciile Web trebuie să fie definite într-o manieră consistentă, astfel încât să 
poată fi ușor descoperite și puse în legătură cu alte servicii și aplicaţii. 

WSDL (Web Service Description Language) desemnează o specificaţie standardizată 
de Consortiul Web si este cel mai cunoscut limbaj folosit pentru a descrie un 
serviciu Web. Prin aceasta descriere se intelege specificarea locatiei si descrierea 
operatiilor (metodelor) permise, aceasta fiind intrucatva similar modului in care 
se face descrierea unei componente (interfete) COM. 


Istoric 


Specificatia WSDL inițială a luat naştere în anul 2000, reprezentând o fuziune a 
două limbaje de descriere a serviciilor: NASSL (Network Application Service 
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Specification Language) propus de IBM si SDL (Service Description Language) provenind 
din partea Microsoft. 

Versiunea actualizată WSDL 1.1 a fost publicată un an mai târziu si trimisă 
Consortiului Web spre standardizare. De fapt, formatul WSDL 1.1 a fost larg 
îmbrățișat de industrie, fiind practic folosit si în prezent. 

WSDL 1.2 nu a depășit stadiul de specificaţie în lucru, fiind compusă din trei 
documentatii (partea de bază, mecanismul de specificare a mesajelor și modul de 
atasare), ultima actualizare fiind realizată în 2003. 

Actualmente, Consorţiul Web lucrează la WSDL versiunea 2.0. 


Caracterizare 


Conceptual, un document WSDL reprezintă un „contract” între o cerere și un 
răspuns, similar modului cum o interfață Java reprezintă un „contract” între 
codul-client și un obiect, instanţă a unei clase Java. Diferenţa esenţială este că 
WSDL poate fi considerat o platformă — și, de asemenea, un limbaj de marcare, 
care este folosit în principal pentru descrierea serviciilor Web accesate via SOAP. 

În figura 2, putem observa cum WSDL, prin intermediul unor descrieri 
standard, face posibilă comunicarea la nivelul de integrare furnizat de serviciile 


Web — a se consulta si capitolele 6 si 7. 
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Figura 2. Maniera de integrare a serviciilor Web via WSDL 
(documentele WSDL oferă descrierea interfetei de interacțiune cu o aplicație 
la nivel de integrare software) 


Cea mai potrivită cale de a înțelege cum este descris un serviciu Web cu 
ajutorul WSDL este de avea o privire de ansamblu asupra modelului său 
conceptual si de a studia construcțiile care formează această descriere. 
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2.1. Modelul conceptual al WSDL 


După cum am văzut, descrierea unui serviciu Web poate fi structurată in două 
parti principale. În partea abstractă are loc descrierea serviciului Web în termeni 
de mesaje trimise si recepționate sub controlul unui sistem de tipuri (în mod curent, 
graţie unei scheme XML). Modelul schimbului de mesaje definește succesiunea 
si cardinalitatea mesajelor. O operație (operation) asociază modelul schimbului de 
mesaje cu unul sau mai multe mesaje. O interfață (interface) grupează aceste 
operații într-un mod independent de transport și de metoda de serializare. 

În partea concretă a descrierii, bindings specifică modul de transport si formatul 
de serializare pentru interfeţe. Elementul endpoint face legătura cu o adresă, iar 
service grupează acele endpoints care implementează o interfață comună (SEI — 
Service Endpoint Interface). 


Mesaje (messages) 


Interfața serviciului 


E 5 
(definitie abstracta) SABER A p) 


Interfaţă (interface) 


E Legare (binding) 
Implementarea serviciului - 
ois : Serviciu (service) 
(definitie concreta) 


| Punct terminal (endpoint) | 


Figura 3. Modelul conceptual WSDL 


Componentele WSDL 


Pentru a descrie un serviciu Web, WSDL furnizează un set de componente și 
proprietăți asociate acestora. 
Avem mai jos forma generală a unui document WSDL: 
<definitions targetNamespace="xs:anyURI"> 
<documentation>? 
[<import> | <include>] * 
<types>? 
[<interface> | «binding» | <service>]* 
</definitions> 


Am folosit următoarele convenţii: meta-caracterul ,,?” desemnează o con- 
structie opţională (elementul <documentation> poate, aşadar, lipsi), caracterele 
» [...]” specifică o grupare de alternative, numele de elemente fiind delimitate 
de „|” (în cazul nostru, poate apărea fie marcatorul «import», fie <include>). 
Simbolul ,,*” specifică zero, una, sau mai multe apariţii (elementele «interface», 
«binding» ofi «service» pot apărea de oricâte ori dorim). 
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În cele ce urmează vom analiza fiecare element in parte, studiind initial 
componentele părții abstracte și apoi pe ale celei concrete. 

Elementul-rădăcină al documentului WSDL este definitions, putând fi văzut ca un 
container care conţine toate informaţiile si atributele asociate unui serviciu Web. 
Figura următoare arată schema generală a elementului <definitions> așa cum este 
ea redată de editorul oXygen pe baza schemei XML oficiale a limbajului WSDL 1.1. 

Atributul /argezNazzespace al elementului definitions este obligatoriu, de tipul 
anyURI. Spaţiul de nume poate defini în mod direct sau indirect semantica 
documentului WSDL. Marcatorul definitions poate avea si alte atribute opţionale 
cărora să le corespundă diferite spaţii de nume folosite în documentul WSDL. 
În versiunea 2.0 a limbajului, sub-elementul por/Type este denumit interface. 

Să considerăm un exemplu concret de utilizare a elementului definition pentru 
specificarea unui serviciu de validare a documentelor XML (implementarea 
efectivă va fi prezentată în cadrul capitolului 6): 


<definitions> 
<!-- numele serviciului Web, 
aşa cum va fi accesat din exterior --> 


<interface name="XMLValidator"> 


</interface> 


<!-- un mesaj SOAP privind transmiterea 
argumentelor de intrare --> 


«message name-"ValidateSoapIn"» 


«/message» 


<!-- un mesaj SOAP privind transmiterea 
raspunsului --> 


«message name-"ValidateSoapOut"» 
«/message» 
<!-- serviciul oferit --> 


«service name="XMLValidator"> 


</service> 


<!-- atasarea (legarea) la protocolul de transport 
efectiv al datelor --> 


«binding name-"XMLValidatorSoap"» 
</binding> 
<binding name="XMLValidatorSoap12"> 
</binding> 

</definitions> 
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definitionsType 


definitions 
http://schemas xmlsoap.org/wsdl/ 


Q message 
http://schemas xmlsoap.org/wsdl/ 


Q, portType 
http://schemas.xmlsoap.org/wsdl/ 


Q binding 
http://schemas.xmlsoap.org/wsdl/ 


Q service 


http://schemas xmlsoap.org/wsdl/ 


& import 


http://schemas.xmlsoap.org/wsdl/ 


Q port 


http://schemas.xmlsoap.org/wsdl/ 


E documentation 
http://schemas.xmlsoap.org/wsdl/ 
0..1 
Eh impoitType 


import 
http://schemas.xmlsoap.org/wsdl/ 


typesType 
types 
http://schemas.xmlsoap.org/wsdl/ 


messageT ype 
message 
http://schemas.xmlsoap.org/wsdl/ 


portTypeT ype 
portType 
http://schemas.xmlsoap.org/wsdl/ 


bindingType 


binding 
http://schemas.xmlsoap.org/wsdl/ 


serviceType 
service 
http://schemas.xmlsoap.org/wsdl/ 


0,.co 


84?» NOT(http://schemas.xmlsoap.org/wsdl/) 


Figura 4. Schema elementului definitions 


DESCRIEREA SERVICIILOR WEB 67 


Elementul zterface include un set de operaţii abstracte. Optional, o interfață 
poate extinde una sau mai multe interfeţe. Un exemplu concret de utilizare a 
elementului 7pferface este următorul: 

<definitions> 

«interface name="XMLValidator"> 
<!-- verifica daca exista un fisier --> 
<operation name="CheckIfExists"> 


</operation> 
<!-- valideaza un document XML --> 
«operation name="Validate"> 


</operation> 
</interface> 
</definitions> 


Elementul operation consta dintr-un grup de mesaje de intrare/iesire legate 
între ele. Execuţia unei operaţii implică transmiterea sau schimbul unor astfel de 
mesaje între serviciul consumator si cel furnizor. Elementul operation al interfeţei 
are ca atribut obligatoriu name, desemnând numele operaţiei expuse. 

Reprezentarea acestor mesaje se face cu ajutorul construcției messages care se 
găseşte întotdeauna ca element-copil direct al marcatorului definition. Numele 
mesajului este apoi referentiat în operaţiile de input/output ale elementelor copil 
(vezi exemplul de mai jos). 


<definitions> 
«message name-"ValidateSoapIn"» 


«/message» 
«interface name-"XMLValidator"» 
«operation name-"Validate"» 
«input name-"msg" message-"ValidateSoapIn" /» 
</operation> 
</interface> 
</definitions> 


Un element message poate contine unul sau mai multi parametri de intrare/ 
ieşire care aparţin operaţiei. Fiecare element part definește un asemenea para- 
metru. El furnizează o pereche nume-valoare împreună cu un tip de data asociat. 
Exemplul următor ilustrează un bloc message având un singur marcator part. 

<definitions> 


«message name-"ValidateSoapIn"» 
«part name-"filename" type="xs:string"> 
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document.xml 
</part> 
</message> 
</definitions> 


La nivelul părții de implementare, un document WSDL poate stabili legături 
concrete cu protocoale cum ar fi SOAP sau HTTP. 

Într-un document WSDL, elementul service constă din unul sau mai multe 
elemente endpoint, la nivelul cărora serviciul Web poate fi accesat. Aceste puncte 
terminale includ informaţii legate de localizare și protocolul permis. 

Alte informaţii specifice protocolului se regăsesc la nivelul elementului binding. 

Să considerăm mai jos un exemplu de utilizare a elementului service (spaţiul de 
nume zns este unul temporar): 

<definitions> 

«service name="XMLValidator"> 
«endpoint name-"XMLValidatorSoap" 
binding="tns:XMLValidatorSoap"> 
<!-- detalii concrete legate de implementar => 
</endpoint> 
</service> 
</definitions> 


Atributul name al elementului service este obligatoriu. 

Elementul binding stabileste protocolul si da informatii despre formatul 
mesajelor operatiilor. Elementul operation din cadrul unui bloc binding seamana cu 
omologul sáu din secțiunea znferface. 

Figura următoare oferă forma generală a elementului binding. 


bindingType 


binding 
http://schemas xmlsoap.org/wsdl/ 


binding_operationType 
operation 
http://schemas.xmlsoap.org/wsdl/ 


Figura 5. Elementul binding 
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Pornind de la această schemă, un exemplu de utilizare a elementului binding 
este: 
<definitions> 
<service> 
<binding name="XMLValidatorSoap"> 
<operation name="Validate"> 
<input>...</input> 
<output>...</output> 
</operation> 
</binding> 
</service> 
</definitions> 


Elementul feature asociat elementului binding definește functionalitátile asociate 
schimbului de mesaje (fiabilitate, securitate, corelaţie si dirijare). Elementul 
property este folosit pentru a controla marcatorul feature. El constă dintr-un set de 
valori posibile specificate printr-o referință la o schemă de descriere. Aceste 
valori pot fi partajate între elementele feature. 

Vom discuta mai departe alte construcţii suplimentare pe care le întâlnim în 
specificațiile WSDL. 

Elementul żnclude ajută la modularizarea descrierii serviciului Web. El permite 
ca parti din definiția unor servicii care se referă la același spaţiu de nume să 
poată fi regăsite într-un alt document WSDL, astfel putând fi folosite sau 
partajate de descrierile serviciilor Web. Atributul /ocation este obligatoriu și rolul 
său este de a specifica locaţia unor astfel de documente WSDL. Valoarea 
spaţiului de nume asociat documentului WSDL inclus trebuie să fie referită de 
spaţiul de nume al elementului definition din documentul WSDL inclus. 

Conceptul din spatele elementului Zzpor? este cumva similar celui privitor la 
include, diferența constând în faptul că documentul WSDL importat poate referi 
un alt spaţiu de nume. Atributul namespace al marcatorului por? este obligatoriu, 
în vreme ce atributul /ocation are caracter optional. 


impottype | O! anySimpleType - 
import (0 namespace 
http://schemas.xmlsoap.org/wsdlf | | — ^ 
= anySimpleType | 
@ location i 


=) documentation 
[E 
http://schemas.xmlsoap.org/wsdl/ 
0..1 


Figura 6. Schema elementului import 
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Elementul “pes defineşte tipurile de date folosite in comunicare. WSDL nu 
este legat exclusiv de un anumit sistem care conţine aceste tipuri, dar implicit 
folosește specificaţiile XML Schema. Dacă serviciul utilizează doar tipuri simple 
(precum șiruri de caractere si întregi), atunci elementul 7ypes nu este obligatoriu. 

Un exemplu de utilizare a elementului 7ypes care stabilește utilizarea tipurilor 
de date XML Schema este următorul: 

<definitions> 

<types> 
<xsd:schema 
elementFormDefault="qualified" 
targetNamespace= 


"http://www.infoiasi.ro/XMLValidator" 
xmlns:xsd-"http://www.w3.org/2000/10/XMLSchema"» 


</xsd:schema> 
</types> 
</definitions> 


Un alt element pe care-l regăsim in forma generală a unui document WSDL 
este documentation. Acesta poate fi inclus in orice document WSDL si este folosit 
in special pentru a furniza o explicaţie textuală ușor de înţeles (human-readable). 

<definitions> 

<documentation> 
Acest serviciu oferă operaţii de validare XML. 


</documentation> 
</definitions> 


Tipuri de documente WSDL 


Sintetizând cele detaliate mai sus, documentele WSDL pot exprima două tipuri 
de informaţii: cele referitoare la interfața serviciului și cele privitoare la imple- 
mentarea efectivă a acestuia. 

După cum am văzut, interfaţa unui serviciu este descrisă de un document 
WSDL care contine elementele /ypes, import, message, interface şi binding. Interfața 
unui serviciu conţine definiția WSDL a acestuia, folosită pentru implementarea 
unuia sau a mai multor servicii. Este o definiţie abstractă a serviciului Web si este 
utilizată pentru a descrie un anumit tip (o clasă) de serviciu. Un document de 
tip interfață poate referi un alt document de tip interfaţă, folosind elementul 
import. 

Un document WSDL de implementare a serviciului contine elementele zzpor? 
si service. Un astfel de document specifică o descriere a serviciului care implementează 
interfaţa serviciului. Măcar unul dintre elementele port va face o referință la 
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documentul WSDL de tip interfata. Un document de implementare a serviciului 
poate îngloba referinţe la mai multe documente de tip interfaţă (aga cum o clasă 
dintr-un limbaj orientat-obiect precum C++ ori Java poate mosteni un număr de 
una sau mai multe clase). 


<definition> 
«types .../> 
«import .../> 
<message .../> 
<interface .../> 
<binding .../> 

</definition> 


Interfata 
serviciului 


<definition> 
«import .../> 
<service .../> 


«port .../> 
</definition> 


Implementarea 
serviciului 


Figura 7. Tipurile de documente WSDL 


Elementul zzport dintr-un document WSDL de implementare contine două 
atribute. Primul este namespace, a cărui valoare este un URI care se potriveşte cu 
targetNamespace din documentul de tip interfaţă. Al doilea atribut este /ocation, 
precizând un URI folosit pentru a referentia documentul WSDL care conţine 
definiția completă a interfeţei serviciului. Atributul binding al elementului port 
specifică o referință la un element binding particular din documentul de tip 
interfaţă. 

Documentul de interfaţă a serviciului este dezvoltat și publicat de un furnizor 
de servicii de interfață (service interface provider). Documentul de tip implementare 
este creat si publicat de un furnizor de servicii (service provider). Rolurile acestui 
furnizor de servicii de interfaţă si a furnizorului de servicii sunt separate din 
punct de vedere logic, dar pot desemna și aceeași entitate emițătoare. 
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2.2. Diferenţele dintre specificaţiile WSDL 1.1 si WSDL 2.0 


De la WSDL 1.2 s-a trecut la WSDL 2.0 si intalnim in principal urmatoarele 
diferente fata de WSDL 1.1: 


e Adăugarea de semantici limbajului de descriere. De asemenea, s-a introdus 
atributul obligatoriu sargetNamespace pentru elementul definitions. 

* Schimbarea modului de construire a mesajului: se folosește sistemul de tipuri 
de date din XML Schema via elementul Apes. 

e Elementul por/lypes este redenumit înferfaces. Suportul pentru moștenirea 
interfeţei este obținut prin folosirea atributului exzends în cadrul elementului 
interface. 

e Elementul port a fost redenumit endpoint. 


2.3. Exemple de documente WSDL 


În cea mai mare parte, dezvoltatorii de servicii Web nu generează manual 
descrieri WSDL pentru serviciile lor. Se utilizează anumite instrumente care 
furnizează documente WSDL în mod automat. 

De exemplu, platforma Microsoft .NET poate genera automat o descriere 
WSDL pentru un serviciu Web. Să considerăm că avem un serviciu Web (vezi 
capitolul 6 pentru detalii) de salutare a utilizatorului. Pentru a accesa descrierea 
WSDL generată trebuie să adăugăm sufixul „?W'SDL” la URI-ul fişierului .asmx. 

Se va obţine o descriere WSDL a serviciului implementat în cadrul fișierului 
.asmx (în exemplul nostru, considerăm serviciul denumit sa/utari.asmx). Facem 
observaţia că pentru generarea automată a documentului WSDL de mai jos s-a 
utilizat INET Framework versiunea 1.1, iar versiunea WSDL folosită este 1.1. 


<?xml version="1.0" encoding="utf-8" ?> 
<definitions 
xmlns:http-"http://schemas.xmlsoap.org/wsdl/http/" 
xmlns:soap-"http://schemas.xmlsoap.org/wsdl/soap/" 
xmlns:s-"http://www.w3.0rg/2001/XMLSchema" 
xmlns:hs-"urn:Hello" 
xmlns:soapenc- 
"http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:tm-"http://microsoft.com/wsdl/mime/textMatching/" 
xmlns:mime-"http://schemas.xmlsoap.org/wsdl/mime/" 
targetNamespace-"urn:Hello" 
xmlns-"http://schemas.xmlsoap.org/wsdl/"-» 
«types» 
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<s:schema elementFormDefault="qualified" 
targetNamespace="urn:Hello"> 
<s:element name="sayHello"> 
<s:complexType> 
<s:sequence> 
<s:element minOccurs="0" maxOccurs="1" 
name="name" type="s:string" 
</s:sequence> 
</s:complexType> 
</s:element> 
<s:element name="sayHelloResponse"> 
<s:complexType> 
<s:sequence> 
<s:element minOccurs="0" maxOccurs="1" 
name-"sayHelloResult" 
type-"s:string" /» 
«/s:sequence» 
</s:complexType> 
</s:element> 
<s:element name="String" nillable="true" 
type="s:string" /> 
</s:schema> 
</types> 
«message name-"sayHelloSoapIn"-» 
<part name-"parameters" element-"hs:sayHello" /» 
«/message» 
«message name="sayHelloSoapOut"> 
«part name-"parameters" 
element-"hs:sayHelloResponse" /-» 
«/message» 
<portType name="SalutariSoap"> 
<operation name="sayHello"> 
<documentation xml:lang="ro"> 
Metoda de salut sayHello(). 
</documentation> 
<input message-"hs:sayHelloSoapIn" /> 
<output message="hs:sayHelloSoapOut" /> 
</operation> 
</portType> 
<binding name="SalutariSoap" type="hs:SalutariSoap"> 
<soap:binding 
transport="http://schemas.xmlsoap.org/soap/http" 
style="document" /> 
<operation name="sayHello"> 
<soap:operation soapAction="urn:Hello/sayHello" 
style="document" /> 
<input> 


/> 
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<soap:body use="literal" /> 
</input> 
<output> 
«soap:body use-"literal" /> 
«/output» 
</operation> 
</binding> 
<service name="Hello"> 
<documentation> 
Un serviciu Web care va saluta. 
</documentation> 
<port name="HelloSoap" binding="hs:HelloSoap"> 
<soap:address 
location="http://localhost/salutari.asmx" /> 
</port> 
</service> 
</definitions> 


În exemplul de mai sus se pot identifica elemente ca <definition>, <message>, 
<portLype> (din versiunea WSDL 1.1), <dinding> etc. 
Reprezentarea grafică a structurilor XML anterioare este dată de figura 8. 


sayHello 


sayHelloResponse 


[se p [ot e 


Co 


= soap:body 


service |E documentation 


E—] soap:address 


Figura 8. Reprezentarea grafică a arborelui de elemente corespunzător unui document WSDL. 
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După cum se poate observa, elementul definitions specifică mai multe spații de 
nume care vor fi utilizate în acest document. 

<?xml version="1.0" encoding="utf-8" ?> 

<definitions 
xmlns:http-"http://schemas.xmlsoap.org/wsdl/http/" 
xmlns:soap-"http://schemas.xmlsoap.org/wsdl/soap/" 
xmlns:s-"http://www.w3.0rg/2001/XMLSchema" 
xmlns:hs-"urn:Hello" 
xmlns:soapenc- 

"http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:tm- 

"http: //microsoft.com/wsdl/mime/textMatching/" 
xmlns:mime-"http://schemas.xmlsoap.org/wsdl/mime/" 
targetNamespace-"urn:Hello" 
xmlns-"http://schemas.xmlsoap.org/wsdl/"» 


Folosirea spatiilor de nume este importantá pentru diferentierea elementelor 
si permite documentului sa facá referinte multiple la specificatii externe, incluzand 
specificații WSDL, SOAP si XML Schema. Atributul zargetNamespace este un 
atribut XML Schema care permite documentului WSDL să facă referire la el 
însuși. Trebuie observat faptul că această valoare trebuie specificată in mod unic 
(diferită de alte spaţii de nume definite). 

Se remarcă, de asemenea, faptul că elementul definitions declară si un spaţiu de 
nume implicit: xmlns-"http://schemas.xmlsoap.org/wsdl/". Elementelor 
care nu au specificat un spaţiu de nume (de exemplu, message sau porfl ype) le 
corespunde acest spaţiu de nume WSDL implicit. 

În documentul WSDL sunt definite două elemente message. 

«message name-"sayHelloSoapIn"-» 

<part name-"parameters" 
element-"hs:sayHello" /> 

«/message» 

«message name="sayHelloSoapOut"> 

«part name-"parameters" 


element="hs:sayHelloResponse" /> 
</message> 


Primul reprezintă mesajul-cerere, sayHelloSoapln, iar al doilea desemnează 
mesajul de răspuns, sayHelloSoapOut. Fiecare din aceste mesaje contine un singur 
element part. Pentru cerere, part specifică parametrii funcției (metodei), iar 
pentru răspuns desemnează valoarea întoarsă de aceasta. În exemplul de mai sus, 
se poate observa că există un singur parametru de intrare pentru care 
type="s:string". La fel, avem un singur parametru de ieșire tot de tip string. 
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Dacă există situaţii in care metoda prezintă mai multe argumente sau retur- 
nează mai multe valori, atunci se specifică mai multe elemente part cores- 
punzătoare. 

Marcatorul por/Iype defineşte o singură operaţie, numită sayHe//o, având un 
singur mesaj de intrare (sayHe/loSoapIn) si un unic mesaj de ieșire (sayHelloSoapOul). 

<portType name="SalutariSoap"> 

<operation name="sayHello"> 
<documentation xml:lang="ro"> 
Metoda de salut sayHello(). 
</documentation> 
<input message-"hs:sayHelloSoapIn" /> 
<output message="hs:sayHelloSoapOut" /> 
</operation> 
</portType> 


Valoarea atributului message trebuie să fie un nume de element XML calificat 
(de forma prefix:nume unde prefix reprezintă prefixul spaţiului de nume 
corespunzător elementului). De exemplu, elementul zzpz/ include un atribut 
message-"hs:sayHelloSoapIn" — prefixul /s se referă la zargetNamespace definit 
mai devreme pentru elementul definitions. 


2.4. Tipuri de operaţii și mesaje 


WSDL suportă patru tipuri de operaţii principale: 


— One-way — serviciul primeşte un mesaj. Astfel operaţia are un singur element 
input. 

— Request-response (cerere-răspuns) — serviciul primeşte un mesaj si trimite un 
răspuns. Operația are un element de zmput, urmat de un element de output. 
Pentru a specifica eventuale erori se poate utiliza elementul optional fanit. 

— Solicit-response (solicitare răspuns) — serviciul trimite un mesaj si primește un 
răspuns. Operația are un element de ou/pz/ urmat de un element de input. În 
același mod se poate utiliza elementul optional fau/t. 

— Notification (înştiinţare) — serviciul trimite un mesaj. Operația are un singur 
element de output. 


Aceste operaţii sunt prezentate in figura următoare. Modelul cerere-răspuns 
este cel mai utilizat pentru serviciile SOAP. 
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<input>0— 
<output> 


Ji <outputs® " | 
Kinput?g n ; c) 


Figura 9. Tipurile de operații suportate de WSDL: 
a) one-way, b) request-response, c) solicit-response, d) notification 


- b) 


Elementul binding furnizează detalii despre modul in care mesajele privitoare 
la o operaţie vor fi transmise prin reţea (de exemplu, prin HTTP POST sau 
SOAP). Elementul binding are atributele name si type: 


| <binding name="SalutariSoap" type="hs:SalutariSoap"> 


Atributul #pe face referinţă la porfT ype definit anterior în document. În cazul 
nostru, elementul binding se refera la hs:SalutariSoap. Altfel spus, elementul binding 
afirma ceva de genul ,,Voi furniza detalii despre modul cum datele operatiei 
sayHello vor fi transportate in Internet". 

Un document WSDL include construcţii SOAP. Aceasta permite specificarea 
de detalii SOAP, cum ar fi un antet SOAP, SOAP encoding style, SOAPAction — vezi 
capitolul urmator. 

Elementul soap:binding indică faptul că legătura cu mecanismul de transport se 
va face prin SOAP. Marcatorul soap:operation desemnează conectarea unei anumite 
operaţii la o anumită implementare SOAP. Atributul soapAction declară faptul cá 
atributul de antet SOAPAction (din cadrul unui mesaj HTTP) este utilizat pentru 
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identificarea serviciului. Elementul soap:body permite specificarea diferitelor detalii 
despre mesajele de intrare/ieșire. 

Marcatorul service desemnează locaţia serviciului. Deoarece este un serviciu 
SOAP, în exemplul de mai sus s-a folosit elementul soap:address si s-a utilizat 
adresa hitp://localhost/ salutari. as >. 


2.5. Platforme si instrumente de lucru cu documentele WSDL 


Vom trece in revistă o serie de instrumente de lucru cu WSDL, lăsând la 
latitudinea cititorului să decidă care este cel mai ușor de utilizat și mai util pentru 
fiecare situaţie în parte. Nu vom mai reveni la platforma .NET și suportul său 
pentru generarea documentelor WSDL (discutate mai sus), însă remarcăm faptul 
că este unul dintre instrumentele cele mai utilizate la ora actuală. 

Fiind dat un fişier WSDL, se poate crea în mod manual un client SOAP 
pentru a invoca serviciul. O alternativă mai bună ar fi o invocare automată a 
serviciului prin folosirea unui instrument WSDL de invocare. Figura de mai jos 
ilustrează acest mecanism: 


Server 


oferind 
doc. WSDL 


invocare automată 


Figura 10. Invocarea automata a unui serviciu Web via un instrument specializat 


În continuare vom enumera cele mai cunoscute instrumente cu ajutorul 
cărora se pot face invocări, validări, generări de documente WSDL: WSIF (Web 
Services Invocation Framework), Stylus Studio’s Web Service Call Composer, XML Spy, 
WTP (însemnând de fapt platforma Eclipse extinsă) si SOAEd*tor. 

Unul din cele mai cunoscute instrumente de invocare este WSIF, proiect initiat 
de către IBM si donat ulterior inițiativei Apache XML — hitp://xml.apache.org/. 
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WSIF este o interfață de programare a aplicaţiilor (API — Application Programming 
Interface) folosită pentru invocarea serviciilor descrise cu ajutorul WSDL. Utilizând 
WSIF, putem realiza o interacțiune cu serviciile Web la un nivel abstract, 
netinand cont de formatul mesajelor sau de protocolul de transport utilizat. 

Poate vă întrebaţi: la ce este util un astfel de instrument? Să ne imaginăm un 
sistem software al unei corporaţii, sistem format din mai multe entităţi software, 
dezvoltate într-o perioadă de zeci de ani. Trebuie creată o aplicaţie care să poată 
utiliza toate aceste entităţi. WSIF rezolvă problema folosind descrierile WSDL și 
permiţând accesul la functionalitatile acestor entităţi într-o manieră independentă 
de protocol și de locaţie. Astfel, indiferent că recurgem la tehnologii ca SOAP 
(Simple Object Access Protocol), EJB (Enterprise JavaBeans) sau JMS (Java Messaging 
Services), totul se concentreaza asupra unui API dependent de WSDL care permite 
accesarea tuturor functionalitatilor. În consecinţă, integrarea tuturor componen- 
telor se poate realiza la nivel declarativ, prin intermediul documentelor WSDL. 

Stylus Studio’s Web Service Call Composer (pe scurt, Stylus) reprezintă un sistem 
care simplifică dezvoltarea serviciilor Web Java, oferind suport pentru găsirea, 
invocarea și testarea oricărui serviciu Web bazat pe Java, dezvoltat într-un cadru 
de lucru (framework) Java, cum ar fi Apache Axis. Vom da mai jos un exemplu al 
modului în care, cu ajutorul aplicaţiei S#/us, putem localiza si invoca metodele 
unui serviciu Web. Așa cum se poate observa și in figura de mai jos, creăm un 


proiect de tip Web Service Call. 


E 3tyIus Studii ui Eutaruris2 Editiun - [United ec «| 


wn File | Edit view Project Debug WebServiceCall SourceControl Tools w 
Hw New | = Convert to XML | 
| E Document Wizards... | DB to XML Data Source 
fe? Open... Ctrl+O pro DTD Schema 
| Clase zwa Java: Text Editor 
BY save Ctrl+s lau] Web Service Call | [1 
Save As... ver XML Document 
vol GP Save all Ctrleshift+s | ie XML Schema 
| x, XQuery File 


Print Setup... 


| var XSLT: Mapper 
Op xu XSLT: Text Editor 
lyr XSLT: WYSIWYG 


Figura 11. Crearea unui apel de serviciu Web (Web Service Call) 
prin utilizarea instrumentului Stylus 
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Pentru a invoca un serviciu Web, trebuie să putem face o referire la adresa 
documentului WSDL propriu. Deoarece e posibil ca nu întotdeauna să cunoaștem 
această adresă, S#/us are inclus un browser UDDI care permite căutarea in 
regiștrii UDDI (vezi capitolul 5). Pentru a realiza o interogare în regiștrii UDDI 
(de exemplu, IBM, Microsoft, SAP ori XMethods), se alege unul dintre aceștia, 
se introduce o interogare (de pildă: „„goog/7”) si se porneşte căutarea. 


Search By 
O Provider © Service 


D:\PROJECTSPARTSETRIWS TK \example\wesdl\GoogleS earch. wsdl 
http: //api. google. com/beta2/wsdl 

http: //api.google.com/GoogleS earch. wsdl 

http: //api. google. com/search/beta2 

http: //mach4.ebphost.net/tree/wsdl/google_groups. wsdl 


Figura 12. Objinerea rezultatelor privitoare la documentele WSDL găsite 


Aşa cum se observă si in figura 12, Sty/us va afișa o lista cu rezultate. Pentru 
exemplificare, vom alege din lista de rezultate documentul WSDL cu URL-ul 
http:/ / api.google.com/ GoogleSearch.wsdl. În acest moment, avem la dispoziţie docu- 
mentul WSDL dorit și putem vedea ce metode pune la dispoziţie serviciul Web 
(în acest caz, cel oferit de motorul de căutare Google). 

Asa cum se observă mai jos, S#/us afișează operaţiile oferite de serviciul Web, 
signatura metodelor, lista parametrilor, precum si un mesaj SOAP necesar pentru 
invocarea operaţiei selectate. Interfața 57/45 oferă posibilitatea de a modifica 
valoarea parametrilor, mesajul SOAP fiind automat actualizat cu noile date introduse. 
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E [Scenario CJ m RE. WSDL URL: | http://api.gooale.com/GoogleS earch.wsdl est 
Operations Name Type Value 
& GoogleSearchService key string YUGwDBROFHKOSFsVsoqLwlu... BH 

S- GoogleSearchPort q sting orange 
doGetCachedPage start int 1 

doGoogleSearch maxResults int 5 [+] 
doSpelingSuggesticn CT II, (E) E 
<?xml version-"1.0" standalone="no"?> 


<SOAP-ENV: Envelope xulns: SOAPSDR1="http: //www.w3. org/2001,/ 
<SOAP-ENV: Body> 


ce y*YUGwDBROFHKOSFxVxoqLwluHOtlqxTjv</key> 
<q>orange</q> 
<start>l</start> 
lts>5</max 


For Help, press F1 


Figura 13. Detalii privitoare la o metodă oferită de serviciul Web dorit a fi invocat 


Din acest moment suntem gata să realizăm invocarea serviciului Web (folosim 
butonul „Send Request’) — a se vedea figura 14. 


‘Scenario! GC) AR wsoLua: mM 
OF{Send Request! Ham Type Vall 
= BoogleSearchService key string Yul 


= GoogleSearchPort 3 string orat 


Figura 14. Invocarea serviciului Web oferit de Google 


Stylus permite apoi inspectarea, in cadrul ferestrei Preview, a rezultatului intors 
de serverul care gazduieste serviciul Web. 


Preview 
> “9 xmins:SOAP-ENY http: //schemas.xmlsoap.org/soap/envelope/ 
= &) (9 = xmins:xsi http: //www.w3.org/1999/XMLS chema-instance 
= (9 xmins:xsd http: //www.w3.org/1999/XMLSchema 
a Ma SOAP-ENV:Body 
L.S 1L P \ Scenario [Untitled] .wesec] H 


Figura 15. Obzinerea răspunsului întors de serviciul Web invocat 


Mai multe detalii despre această aplicație comercială puteți găsi la adresa 


hitp:/ / www.stylusstudio.com/ . 
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Un alt instrument este XMLSpy care, pe lângă alte facilități oferite, poate fi 
folosit pentru invocarea, editarea, vizualizarea si validarea documentelor WSDL. 
Să considerăm un serviciu Web de generare a numerelor prime. Pentru a-l putea 


invoca avem nevoie de documentul WSDL asociat, pe care îl putem găsi la 
adresa bttp://wnw50.brinkster.com/vbfacileinpt/np.asmx?wsdl. 

XMLSpy permite invocarea rapidă a serviciului Web numit Prime Numbers, 
implementat in Visual Basic .NET, folosind acest document WSDL. 


Project Send request to server 


Figura 16. Crearea unei cereri SOAP de invocare a unui serviciu Web 


Se creează o cerere SOAP care primește ca parametru URL-ul de mai sus: 


Choose a file: 


2290, brinkster.com/vbfacileinpt/np. asmx ?wsdl v] 
Cancel 


Please choose a file from your hard disk or select one of the other windows currently open in XMLSpy. 


Figura 17. Introducerea adresei documentului WSDL folosit 
pentru invocarea serviciului Web dorit 


Acest serviciu Web ne oferă o singură metodă — GetPrimeNumbers. Mesajul 
SOAP creat de instrumentul XMLSpy este ilustrat în figura 18. 


A <SO4P-ENY:Envelope xmins:SOAP-EN'V="http: /schemas.xmlsoap.org/soap/envelope/" 
xmins: SOAP-ENC="http: schemas .xmlsoap.org/soap/encoding/" xmins:xsi=" 
http: eve v3.0rg/2001 (XML Schema-instance" xmins:xsd=" 
http: Awww vv3.org/2001 «ML Schema" 
=SOAP-ENY: Body> 
i <m:GetPrimeNumbers xmins:m="http: //vevevw/50 brinkster com/vbfacileinptinp"- 
i i «m:Max>29=im:Max> 
i <im:GetPrimeNumbers= 
=/SOAP-ENV: Body= 
=- <ISOAP-ENY:Envelope> 


| Text | Grid | Schema/w'SDL | Authentic | Browser | 


Figura 18. Generarea unei cereri către un serviciu Web 
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Trimitem cererea SOAP și răspunsul obţinut va fi: 


LE?xmi version="1 .0" encoding="utf-8"?> 
[-] «soap:Envelope xmins:soap="http: //schemas xmlsoap.orag/soap/envelope/' xmins:xsi=" 
http: Aevi 3 .org/2001 ML Schema-instance" xmins:xsd=" 
http: Aww vw org/2001 SKMLSchema"> 
=<soap:Body> 
i <GetPrimeNumbersResponse xmins="http:/Avwyw50.brinkster.com/vbtacileinptinp"> 
i d zGetPrimeNumbersResult1,2,3,5,7,11,13,17,19,23,29«/ 
GetPrimeNumbersResult- 
i <iGetPrimeNumbersResponse> 
s/soap: Body= 
- <fsoap:Envelope= 


Figura 19. Objinerea răspunsului oferit de serviciul Web invocat 


Facem observaţia cá XMLSpy poate fi găsit și în cadrul mediului Echpse 
(platformă universală de dezvoltare software implementată în Java, scopul său 
fiind integrarea diferitelor instrumente utile, într-o manieră indiferentă de limbajul 
sau platforma folosită). Această integrare permite utilizatorilor sistemului Eclipse 
să lucreze cu tehnologiile standard XML, utilizând numeroasele facilități oferite 
in acest caz de XMLSpy. 

O altă abordare este cea oferită de <oXygen /> XML Editor, care pune la 
dispozitie un instrument de consultare si invocare via SOAP a serviciilor Web. 
În captura din figura 20 ilustrăm acest mecanism. Se poate observa structura 
fişierului WSDL returnat de Google, având acces la numele operaţiilor imple- 
mentate. De asemenea, oXygen poate fi folosit în conjunctie cu Eclipse. 

Alte exemple notabile sunt Wsd/pu// (instrument de inspectare si invocare a 
serviciilor Web) si WSDL Verify (program de verificare a corectitudinii docu- 
mentelor WSDL). 

Ín final, putem concluziona cá folosirea documentelor WSDL aduce cáteva 
avantaje majore: 


e WSDL face mai facilă scrierea și menţinerea serviciilor prin furnizarea unei 
abordări structurate, necesară definirii interfeţei serviciului Web; 

e specificatia WSDL permite o modalitate mai eficientă de a utiliza un serviciu 
Web, prin faptul că reduce mărimea codului (si astfel si a potentialelor erori) 
pe care aplicatia-client trebuie să-l implementeze; 

e WSDL permite ca modificările ulterioare ale interfetei/implementarii ser- 
viciului să se realizeze mai ușor. Descoperirea dinamică a descrierilor WSDL 
conduce la faptul că monitorizarea acestor schimbări va fi automat realizată 
în cazul clienţilor, recurgând la WSDL pentru invocarea serviciilor Web 
dorite. 
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V3 WSDL SOAP Analyser 


WSDL 


Services GoogleSearchService 


Ports GoogleSearchPort 


< || 


[e 4- «1I doGetCachedPage 
; oGetCachedPage 

Actions doSpellingSuggestion 

URL: loGoogleSearch 


SOAP Action | urn:GoogleSearchAction 


Request | attachments | 

«SOAP-ENV:Envelope xrins:SOAP-ENV-"http://schemas.xmlsoap.org/soap/envelope]" > 
«SOAP-ENV:Header/ > 

«SOAP-ENV:Body > 


<oxy:doGetCachedPage xmins:oxy="urn:GoogleSearch" 
SOAP-ENWV :encodingStyle-"http:/Jschemas.xmlsoap.org/soap/encoding/" > 
<key>STRING</key > 
<url>STRING <jurl> 


«joxy:doGetCachedPage > 
</SOAP-ENY:Body> 
</SOAP-ENY: Envelope > 


Figura 20. Pregătirea invocării unui serviciu Web prin intermediul instrumentului WSDL 
SOAP Analyser oferit de oXygen 
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Capitolul 4 
Protocolul SOAP 


„Lotul ar trebui să fie cât mai simplu cu putinta, 
însă nu mai simplu de atât.” 
(Albert Einstein) 


1. Evoluţia protocoalelor bazate pe XML 


Tehnologia din spatele serviciilor Web este construită pe baza protocoalelor 
XML. Acestea guvernează modul cum are loc comunicarea între programele 
rulând la nivel de server și de client și cum sunt reprezentate datele transmise 
(parametrii de intrare și rezultatul întors). 

Din punct de vedere istoric, protocoalele de comunicaţie bazate pe XML se 
împart în două generaţii: prima se bazează doar pe sintaxa XML 1.0, iar a două 
generaţie folosește XML Schema si spaţiile de nume XML. SOAP se încadrează 
în această a doua generaţie. 


1.1. Prezentare succintă a protocoalelor din prima generație 


S-au făcut numeroase eforturi pentru a crea protocoale bazate pe XML. Două 
dintre ele s-au impus în mod deosebit: WDDX (Web Distributed Data Exchange) şi 
XML-RPC. 

WDDX a fost creat in 1998 de Allaire Corporation (preluată de Macromedia, 
devenita in acest moment parte a companiei Adobe). WDDX oferea un meca- 
nism independent de limbaj si platforma pentru schimbul de date intre aplicatii. 
Desi WDDX suporta tipuri de date precum siruri de caractere, numere, valori 
booleene, tablouri și structuri, nu putea fi folosit pentru reprezentarea oricăror 
tipuri de date ce pot fi exprimate în XML. 

WDDX nu era legat în mod strict de o modalitate de transport, astfel că 
aplicaţiile puteau interschimba pachete WDDX folosind diverse protocoale 
precum HTTP sau SMTP. În trecut, WDDX s-a bucurat de un anume succes, 
existând implementări în majoritatea limbajelor de programare. 
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XML-RPC este un protocol bazat pe paradigma RPC (Remote Procedure Call), 
descrisă in primul capitol al acestui volum. XML-RPC a fost introdus in 1998 de 
compania Userland. Tipurile de date suportate sunt similare cu cele din WDDX. 
Ca protocol de transport se foloseste HTTP. 

Un mesaj XML-RPC reprezinta de fapt o cerere HTTP prin metoda POST. 
Corpul cererii are forma unui document XML. Procedura se executa pe server, 
iar rezultatul este întors, de asemenea, sub forma de XML. 

Parametrii de intrare ai procedurii invocate pe server pot fi numere, șiruri de 
caractere etc., sau pot fi structuri ori liste de structuri. 

Un exemplu de cerere XML-RPC este următorul, în care se dorește invocarea 
funcției furnizeazaNumeS ortiment(int), cate va oferi numele unui sortiment de 
portocale pe baza unui index (în acest caz, indexul are valoarea 2): 

POST /RPC2 HTTP/1.0 

User-Agent: Test/3.2 (WinXP) 

Host: tsxmlrpc.ex.ro 


Content-Type: text/xml 
Content-Length: 181 


<?xml version="1.0"?> 
<methodCall> 
<methodName>furnizeazaNumeSortiment</methodName> 
<params> 
<param> 
<value><int>2</int></value> 
</param> 
</params> 
</methodCall> 


Observam ca in antetul cererii URI-ul nu este specificat. De exemplu, el ar 
putea fi vid (doar un singur ,,/”), în cazul in care serverul manipulează doar 
apeluri XML-RPC. 

Oricum, dacă serverul operează cereri HTTP de diferite tipuri, atunci pe baza 
valorii URI mesajele se dirijează spre codul responsabil cu cererile XML-RPC. 
În exemplul de mai sus, URI-ul este /RPC2, aceasta indicând serverului dirijarea 
cererilor spre aplicaţia „RPC2”, care va trimite răspunsul. Este obligatoriu ca în 
antet să fie specificate câmpurile User-Agent şi Host. 

Valoarea câmpului Content-Type este text/xml, deoarece transmitem un docu- 
ment XML, iar Content-Length reprezintă dimensiunea care trebuie corect spe- 
cificată. 

Corpul mesajului este marcat in XML și contine, in acest exemplu, o 
singură structură </pe/hodCa//>. Elementul <methodCal/> trebuie să includă un 
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sub-element <methodName>, care indica (sub forma unui sit de caractere) numele 
metodei apelate. 

Daca procedura invocată la distanță necesită parametri, atunci </methodCall> 
trebuie să conţină și elementul-copil <params>. Acesta va include un anumit 
număr de elemente <param>, fiecare având o valoare de un anumit tip. În 
exemplul anterior, tipul parametrului este 77 si este furnizat chiar de marcatorul 
m. 

Un exemplu de ráspuns pentru cererea de mai sus va avea forma: 

HTTP/1.1 200 OK 

Connection: close 

Content-Length: 158 

Content-Type: text/xml 


Date: Mon, 20 Feb 2006 19:33:07 GMT 
Server:Test/3.2-WinXP 


<?xml version="1.0"?> 
<methodResponse> 
<params> 
<param> 
<value> 


<string>Portocale japoneze</string> 
</value> 
</param> 
</params> 
</methodResponse> 


Daca nu apar erori, se intoarce codul de stare 200 OK. Valoarea campului de 
antet Content-Type este text/xml, deoarece răspunsul este si el un document XML. 
Campul Content-Length trebuie sa fie prezent si sa aiba o valoare corecta. 

Corpul mesajului este o structură XML <mmethodResponse>, care contine un 
singur parametru <params> cu un unic element-copil <param>. Acesta, la rândul 
lui, include o singură valoare <value>. 

Elementul </ethodResponse> putea contine, de asemenea, marcatorul </au/t> 
având sub-elementul <va/we>, ce reprezintă un <stucf> compus din două 
elemente: primul este <fau/tCode>, de tip «nf, iar celălalt este numit <fau/tString> 
si este de tip <string>. Elementul <fault> indică apariţia unei excepţii XML-RPC, 
serverul întorcând codul acesteia si un mesaj explicativ. 

De notat că <methodResponse> poate contine fie <fault>, fie <params>, dar nu 
pe ambele simultan. 

Pentru cererea anterioară putem avea și următoarea variantă de răspuns, 
indicând o excepţie referitoare la furnizarea unui număr prea mare de parametri 
de intrare: 
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HTTP/1.1 200 OK 

Connection: close 

Content-Length: 426 

Content-Type: text/xml 

Date: Mon, 20 Feb 2006 19:33:09 GMT 
Server: Test/3.2-WinXP 


<?xml version="1.0"?> 
<methodResponse> 


<fault> 
<value> 
<struct> 
<member> 
<name>faultCode</name> 
<value><int>4</int></value> 
</member> 
<member> 
<name>faultString</name> 
<value> 
<string>Too many parameters.</string> 
</value> 
</member> 
</struct> 
</value> 
</fault> 


</methodResponse> 


Datorită simplităţii sale, XML a fost acceptat pe scară largă. Astfel, XML-RPC 
poate fi folosit în cadrul programelor Perl, Java, Python, C, C++, PHP şi multe alte 
limbaje. Implementarile sunt disponibile pentru majoritatea sistemelor de operare. 
Un exemplu de aplicaţie Web scrisă în PHP si utilizând XML-RPC este oferit in 
cadrul lucrării lui Sabin Buraga (coord.), Ap/icazii Web la cheie, Polirom, Iasi, 2003. 


1.2. Dezavantajele protocoalelor din prima generaţie 


Enumerăm în cele ce urmează principalele neajunsuri ale primei generaţii de 
protocoale de transport bazate pe XML: 

Lipsa de extensibilitate. Creatorii protocolului trebuie să ajungă la o înţelegere 
înainte ca orice modificări să fie implementate și versiunea protocolului trebuie 
să fie revăzută, astfel încât să se permită diferitelor instrumente să facă distincția 
între versiunile vechi si cele noi ale protocolului. De exemplu, atunci când in 
XML-RPC si WDDX s-a adăugat suport pentru datele binare, specificaţiile 
ambelor protocoale au fost reactualizate si același lucru s-a întâmplat cu toate 
implementările existente pentru diferite limbaje și platforme de programare. O 
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astfel de necesitate constituie un serios handicap, care a fost depășit de pro- 
tocoalele din a doua generaţie prin utilizarea spaţiilor de nume XML. 

A două mare problemă este legată de “purile de date. Aceste protocoale 
foloseau un singur DTD (Document Type Definition) pentru a descrie reprezentarea 
serializată a datelor. În general se utilizau doar câteva tipuri de date simple XML. 
Această abordare a permis multor instrumente să ofere suport acestor protocoale. 
Dificultatea care a apărut ulterior a fost aceea că datele din mesaje erau exprimate 
sintactic și nu semantic. Protocoalele din a doua generaţie folosesc structurile si 
bogatele tipuri de date din XML Schema. 


2. SOAP — scurtă istorie 


Începând cu anul 1997, corporatia Microsoft a iniţiat numeroase cercetări legate 
de XML. Scopul era crearea de aplicaţii care să comunice pe baza RPC și HTTP. 
Companiile DevelopMentor si Userland și-au adus aportul la aceste studii. La 
începutul anului 1998, s-a dezvoltat conceptul de protocol de comunicaţii bazate 
pe XML, numit SOAP. 

În cadrul Microsoft, grupul DCOM (Distributed Common Object Model) nu agrea 
aceasta nouă direcţie și susținea cá Microsoft ar trebui să folosească poziţia 
dominantă pe care i-o oferea DCOM. Altă grupare din Microsoft era de acord 
cu tranziţia la SOAP, însă se considera că era nevoie de ceva mai mult decât 
XML simplu (ar fi fost de dorit suportul oferit de specificațiile referitoare la 
spaţiile de nume și schemele XML). Datorită acestor tergiversări, Userland a 
făcut public în vara anului 1998 protocolul XML-RPC. 

În 1999, Microsoft a creat propria versiune de schemă XML (numită XML 
Data Reduced) şi a adăugat facilități pentru suportarea spaţiilor de nume. Astfel, 
protocolul SOAP începea să capete contur. Era totuși un mecanism de transport 
XML bazat pe RPC. În aceeași perioadă, o echipă care lucra la serverul BizTalk 
a creat un model care se focaliza mai putin pe RPC si mai mult pe ideea de 
transfer de mesaje (messaging). 

Pentru a rezolva aceste diferenţe au fost necesare câteva luni. În septembrie 
1999, apare versiunea publică SOAP 0.9, dată spre aprobare la IETF (Internet 
Engineering Task Force). După câteva schimbări, în decembrie 1999 e disponibilă 
varianta SOAP 1.0. 

Pe 8 mai 2000, SOAP versiunea 1.1 a fost prezentată ca document al 
Consortiului Web, la care IBM era co-autor al protocolului. Această specificaţie 
se caracteriza printr-o mai mare extensibilitate și a eliminat îngrijorările conform 
cărora implicarea Microsoft ar conduce dezvoltatorii la necesitatea utilizării unor 
tehnologii proprietare. 
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În curând, după apariţia specificatiel SOAP 1.1, IBM a lansat pe piaţă 
implementarea Java SOAP, pe care a cedat-o mai apoi proiectului Apache XML 
(http:/ /xml.apache.org/), în scopul unei dezvoltări open source. Ulterior, mai multe 
corporaţii au început să lucreze la implementări ale serviciilor Web folosind SOAP. 

Pe 9 iulie 2001, grupul W3C a publicat o nouă schiță (working draft) pentru 
SOAP 1.2, iar la data de 7 iunie 2003, noua versiune SOAP 1.2 a devenit 
recomandare standardizată. Începând cu varianta 1.2, termenul „SOAP” nu se 
mai consideră a fi un acronim. 

Ca majoritatea tehnologiilor noi, SOAP schimbă regulile după care sunt 
dezvoltate aplicaţiile. Din experienţa cu alte tehnologii, s-a observat că acelea 
care se caracterizează prin simplitate sunt cele mai promovate și au șansa să 
dureze. Asa cum se va vedea din exemplele viitoare, într-o anumită măsură, 
protocolul SOAP se dovedește a fi simplu de înţeles și de utilizat. 


3. SOAP — o vedere de ansamblu 


Serviciile Web sunt o instanță a modelului arhitecturilor orientate spre servicii 
(SOA — Service Oriented Architecture), care folosesc SOAP ca mecanism de transport 
a mesajelor între servicii descrise cu ajutorul unor interfețe WSDL. În esenţă, 
avem de-a face cu o arhitectură simplă (vezi figura 1) în care mesajele SOAP 
sunt propagate cu ajutorul unui protocol de transport între serviciul Web și 
posibilii săi clienţi. 


Serviciu Web Serviciu Web 


Interfaţă Interfaţă 


Mesaje SOAP 


Protocol de transfer ( 


Stiva de protocoale Internet (TCF 


Figura 1. Stiva logică a serviciilor Web 
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SOAP reprezintă un protocol care permite atât schimbul de informaţii 
structurate într-un mediu distribuit si descentralizat, cât si accesarea de servicii, 
privite la nivel orientat-obiect, într-o manieră independentă de platformă. 

Scopul principal al SOAP este facilitarea inter-operabilitatii între platforme si 
limbaje de programare. Pentru realizarea schimbului de informaţii între sisteme 
eterogene, părțile care comunică trebuie să cadă de acord asupra unei reprezentări 
comune. Așa cum se poate observa din exemplul următor, un număr de telefon 
poate avea mai multe reprezentări echivalente din punct de vedere logic 
(semantic). 


<nrTelefon>0232 201090</nrTelefon> 


<nrTelefon> 
<prefix>0232</prefix> 
<numar>201090</numar> 

</nrTelefon> 


<nrTelefon prefix="0232" numar="201090" /> 


Apare întrebarea: care este codificarea corectă? Răspunsul: este corectă cea pe 
care aplicaţia o așteaptă. Cu alte cuvinte, nu este suficient să afirmăm că serverul 
si clientul folosesc XML pentru a realiza schimbul de informaţii. Trebuie să 
definim tipul datelor interschimbate, maniera de modelare a datelor în XML, 
mecanismul de transmitere a informaţiei, folosind — la nivel mai scăzut — 
protocoalele Internet existente. 

Fără aceste convenţii, programele nu pot cunoaște modul de decodificare a 
datelor pe care le primesc, chiar dacă sunt reprezentate cu ajutorul XML. SOAP 
este cel care furnizează aceste convenții. 

Arhitectura generală SOAP (despre care vom discuta în detaliu în cadrul 
subcapitolelor următoare) este surprinsă în figura 2. 

Un mesaj SOAP constă dintr-un document XML al cărui element-rădăcină 
are denumirea de plic (envelope). În interiorul mesajului întâlnim două elemente- 
-copil cunoscute ca antet (header) si corp (body), similar mesajelor transmise prin 
posta. Informaţiile privind modul de interacțiune cu aplicaţiile sunt plasate în 
interiorul corpului, iar în cadrul antetului se găsesc informaţii despre destinatar, 
despre entitatea care va avea posibilitatea modificării mesajului respectiv etc. 

În acest capitol, vom prezenta o serie de exemple de mesaje SOAP sub formă 
de documente XML. Specificaţiile SOAP se referă la un mesaj SOAP ca fiind 
specificat formal printr-un XML Infoset (vezi capitolul 2), descriere abstractă a 
conţinutului său. Cititorii interesaţi de astfel de aspecte (de exemplu, asocierea 
SOAP cu alte protocoale, caz în care mesajele pot avea reprezentări diferite) le 
pot găsi în rapoartele tehnice furnizate de Consorţiul Web. 
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Expeditor Destinatar 
(sender) (receiver) 
Orice tip de continut 
Sistem SOAP Sistem SOAP 


Internet 


(eventual, 
intermediari) 


Figura 2. Arhitectura SOAP 


4. Forma generala a unui mesaj SOAP. 
Procesarea datelor de catre serverele SOAP 


Mesajele SOAP sunt documente XML care reprezinta structura atomica pentru 
comunicarea în medii distribuite. Elementul-rădăcină al unui mesaj SOAP este 
marcatorul Envelope. Deoarece elementul Envelope este in mod unic identificat de 
propriul său spaţiu de nume, instrumentele de procesare vor putea determina cu 
ușurință dacă un document XML reprezintă sau nu un mesaj SOAP. 

Putem să imaginăm un mesaj SOAP ca pe un plic (SOAP Envelope) care 
contine în interior un antet (heade) optional si un corp (body) obligatoriu — a se 
consulta figura 3. 

Antetul contine blocuri de informaţii relevante pentru modul cum va fi 
procesat mesajul. Acesta include date privitoare la locaţia emitentului, locaţia 
destinatarului, anumite informaţii de autentificare și autorizare. Corpul stochează 
mesajul care va fi trimis și procesat. Orice aspect ce poate fi exprimat cu ajutorul 
sintaxei XML poate fi memorat în corpul mesajului. 
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Plicul SOAP (Envelope) 


Antetul SOAP (Header) 
Bloc antet 


Bloc antet 


Corpul SOAP (Body) 


Bloc corp 


Bloc corp 


Bloc corp 


Bloc corp 


Figura 3. Structura unui mesaj SOAP 


După cum se poate observa, există aici — ca si în cazul poștei electronice — 
O separare între partea destinată aplicaţiilor propriu-zise si partea de transport. 
Informaţiile destinate aplicaţiilor le găsim la nivelul corpului mesajului, pe 
când elementele legate de transportul mesajului sunt incluse doar în partea de 
antet. 

Ne putem imagina că o aplicație SOAP este formată din noduri (entități de 
calcul intermediare) care schimbă mesaje între ele. Mesajele SOAP pot trece 
printr-un număr oarecare de noduri intermediare până ajung la destinatarul 
final. 

Specificatiile SOAP presupun existenţa unor noduri intermediare care descriu 
comportamentul unui nod în anumite circumstanţe. Un mesaj, care trece din 
nod în nod pentru a ajunge în final la destinatar, poate fi procesat de aceste 
noduri intermediare (vezi figura 4). Mai mult, un astfel de nod poate realiza 
modificări în cadrul unui mesaj, astfel încât acesta să poată fi procesat de un nod 
diferit de cel final. 
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Serviciu Web 
Receptor 
iat liar ; 


Fluxul de mesaje SOAP 


Figura 4. Nodurile SOAP si fluxul mesajelor vehiculate 


Asa cum se observa in figura 4, nodurile intermediare primesc mesajul si il 
pot altera sau nu. Nodul final se numeşte si u/timate receiver, adică este nodul 
terminal pe care se află serviciul Web care va folosi acel mesaj. 

Întregul model de procesare este implementat de către serverele SOAP, Un 
server SOAP desemnează un element al mecanismului care face medierea între 
traficul SOAP și componentele unei aplicaţii. Pentru a putea dezvolta servicii 
Web, trebuie să înţelegem modul în care un server SOAP implementează modelul 
SOAP. 

Pornind de la premisa că este imposibil să facem o trecere în revistă a tuturor 
platformelor SOAP existente, vom prezenta arhitectura generală a unui server 
SOAP. De asemenea, vom enumera principalele caracteristici de care se bucură 
cele mai populare implementări actuale — a se vedea si capitolul 6 pentru 
exemple de aplicaţii (servere și clienți) utilizând SOAP. 

O imagine generală a unui server SOAP poate fi urmărită în figura 5. 

Considerăm scenariul in care un mesaj SOAP a ajuns la un server SOAP. 

Aşa cum se poate observa, elementele stocate în antetul mesajului SOAP (de 
exemplu, informaţii caracteristice pentru alte servicii Web cum ar fi securitatea, 
tranzacţiile etc.) sunt procesate de anumiţi „lucrători” (handlers) care au fost 
înregistrați pentru serviciul Web în cauză. Astfel de entităţi (în fapt, funcţii de 
tratare a antetelor) sunt considerate — în termenii SOAP — noduri intermediare. 

Rutinele de tratare a antetelor nu fac implicit parte din serverele SOAP, dar 
sunt în general utilizate pentru îmbunătăţirea capacităţilor serverului. Aceasta 
înseamnă că serverele SOAP pot fi la rândul lor perfecționate ulterior, pentru a 
fi compatibile cu noile tehnologii/servicii Web care apar. 

Dacă în urma procesării antetului nu s-a obţinut nici o eroare, partea de mesaj 
care e destinată aplicaţiei (care se găsește în corpul SOAP) ajunge la nivelul de 
dispecer (dispatch), care transmite implementării serviciului datele propriu-zise de 
intrare. După efectuarea procesării în interiorul serviciului, are loc trimiterea 
răspunsului către dispatcher, care-l va propaga către entitatea ce a formulat 
cererea. Așa cum se poate remarca din figura 5, mesajul de răspuns poate trece 
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prin mai multe etape de transformări. Anumiți sandler-i (noduri intermediare) pot 
modifica antetul mesajului. Altfel spus, dacă revenim la analogia mesaj SOAP — 
plic, e ușor să ne imaginăm cum acesta ajunge să fie adus de un postas la 
destinaţie, dar înainte de aceasta a trecut prin mai multi „intermediari” (societăți 
de transport, oficii poștale etc.) care l-ar fi putut modifica. Aceste modificări 
sunt realizate doar la exteriorul plicului (de exemplu, diverse stampilari), con- 
ţinutul lui rămânând intact până ajunge la destinatar. 


mpiementarea Serviciulul We 


Dispecer 


(dispatcher) 


<iEnvelope> 


TCP/IP (protocoale de transport Internet) 


Figura 5. Arhitectura generală a unui server SOAP 


Eventual, mesajul poate ajunge la un nivel de reţea în care este transformat 
(marshalled) pentru a suporta un anumit protocol de nivel scăzut (de exemplu, 
SMTP ori HTTP), însă va fi trimis într-un mod corespunzător nodurilor SOAP 
pentru a putea fi procesat. 


98 SERVICII WEB 


5. Modelul SOAP — mesaje si codificări 


Pornind de la premisa că toate cele discutate până acum v-au stârnit curiozitatea 

și v-au familiarizat cu noțiunile importante ale protocolului, vom încerca să 

prezentăm în detaliu elementele care contribuie la crearea modelului SOAP. 
Specificatia SOAP este divizată în trei componente: 


— prima constă într-o descriere a utilizării protocolului SOAP, a structurii 
mesajelor si a modelului conform căruia se realizează schimbul de mesaje 
SOAP; 

— partea a doua (Messaging Framework) furnizează un model în care se specifică 
regulile de procesare a unui mesaj SOAP, un cadru de lucru extensibil care 
permite dezvoltatorilor să utilizeze extensii în cadrul sau în afara mesajului 
SOAP, reguli pentru construcția mesajelor SOAP și legături între SOAP si 
diferite protocoale (cum ar fi HTTP); 

— partea a treia (Adjunct) prezintă, printre altele, regulile pentru realizarea unui 
apel SOAP RPC si regulile de codificare a mesajelor SOAP. 


În secţiunile următoare, vom prezenta modelul de bază şi structura docu- 
mentelor XML, schemele de codificare, convențiile RPC utilizate și legătura 
SOAP cu protocoalele de transport. 


5.1. Mesajele SOAP 


Dacă până în acest moment ne-am făcut o idee generală privitoare la structura 
per ansamblu a unui mesaj SOAP, în această secțiune vom începe studierea 
concretă a unor exemple. 

Reamintim că un mesaj SOAP trebuie să includă cel puţin un bloc de date în 
corpul mesajului și că antetul este opțional. De altfel, nu există o limită superioară 
a numărului de blocuri ce pot apărea în antet sau în corp. 

Fie următorul exemplu de mesaj SOAP, vehiculând date referitoare la achi- 
ziţiile si vânzările unor sortimente de portocale: 

<?xml version="1.0" encoding="UTF-8"?> 

<env: Envelope 


xmins:env="http://www.w3.org/2002/06/soap-envelope"> 
<env:Header> 


<tz:tranzactie-id 
xmlns:tz="http://tranzactie.portocale.info" 
env:encodingStyle= 
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"http://tranzactie.portocale.info/enc" 
env: role= 
"http: //www.w3.org/2002/06/soap- 
nvelope/role/ultimateReceiver" 
env:mustUnderstand="true"> 
tranz10-01 
</tz:tranzactie-id> 
</env:Header> 
<env:Body xmlns:p-"http://www.portocale.info/"» 
<p:portocale> 


<!-- partea de achizitie de portocale --> 
<p:achizitii env:encodingStyle= 
'http://www.w3.0rg/2002/06/soap-encoding"» 
<p:tip>Portocale greceşti fără coaja</p:tip> 
<p:cod>P10-01-GR</p:cod> 
<p:cantit p:um="kg">3374</p:cantit> 
</p:achizitii> 
<!-- partea de vânzări de portocale --> 
<p:vanzari> 
<p:tip>Portocale japoneze albastre</p:tip> 
<p:cod>P10-03-JP</p:cod> 
<p:cantit p:um="kg">0107</p:cantit> 
</p:vanzari> 
</p:portocale> 
</env:Body> 
</env:Envelope> 


Dacă urmărim structura acestui mesaj, observăm că respectă modelul pre- 
zentat în figura 2. Mesajul din exemplul nostru conţine un singur bloc-antet, iar 
în corp întâlnim două elemente (care vor fi utilizate de destinatarul final). Atât 
elementul Header, cât si Body sunt copiii marcatorului Envelope care, de fapt, joacă 
rolul unui container de date. 


5.2. Elementul Envelope 


Elementul Envelope este elementul în interiorul căruia se găsește mesajul SOAP. 
Acest element are asociat spaţiul de nume de la adresa J/ip:/ / wwm.w3.org/ 2002/ 
06/ soap-envelope. 

Ín exemplul anterior, identificarea acestui spatiu de nume se face prin prefixul 
en. 

Xenv: Envelope 


xmlns:env-"http://www.w3.0rg/2002/06/soap-envelope"-» 
<!-- parte opțională --> 
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<env:Header> 


</env:Header> 
<!-- un singur element Body (obligatoriu) --> 
<env:Body xmlns:p-"http://www.portocale.info/"» 


</env:Body> 
</env:Envelope> 


Elementul Envelope poate avea maxim două elemente-copil: Header si Body. De 
asemenea, Envelope trebuie să conţină si declaraţiile spaţiilor de nume care sunt 
folosite în interiorul mesajului. 


5.3. Elementul Header 


Dacă acest element apare, atunci el trebuie să fie primul element-copil al 
marcatorului SOAP Envelope. Elementul Header poate contine un set de intrări, 
fiecare element încapsulat de Header purtând numele de bloc antet. 

Scopul unui bloc antet este de a comunica informaţia relevantă în procesarea 
mesajului SOAP. Un exemplu ar putea fi un bloc antet care conţine elemente de 
autentificare sau informaţii despre ruta (drumul) mesajului. 

Elementul Header are asociat spaţiul de nume specificat de adresa hitp://www.w3.org/ 
2002/ 06 / soap-envelope. 


<env:Envelope 
xmins:env="http://www.w3.org/2002/06/soap-envelope"> 
<env:Header> 
<tz:tranzactie-id 
xmlns:tz="http://tranzactie.portocale.info" 
env: encodingStyle= 
"http: //tranzactie.portocale.info/enc" 
env: role= 
"http: //www.w3.org/2002/06/soap- 
envelope/role/ultimateReceiver" 
env: mustUnderstand="true"> 
tranz10-01 
</tz:tranzactie-id> 
</env:Header> 


</env:Envelope> 


Fiecare bloc antet trebuie să aibă asociat un spaţiu de nume calificat (în acord 
cu regulile din SOAP Schema). Modul de codificare a datelor se realizează prin 
intermediul atributului encodingStyle, iar nodul care trebuie să-l proceseze se specifică 
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prin atributul rok. De asemenea, poate contine si atributul mustUnderstand, cu 
ajutorul căruia se poate solicita ca un nod SOAP să-l înţeleagă sau nu. 

În specificaţiile SOAP este clar definit faptul că atributele rok si mustUnderstand 
pot apărea doar în declaraţiile blocurilor antet. De altfel, emițătorul unui mesaj 
SOAP trebuie să plaseze aceste atribute cu mare grijă. Dacă ele sunt amplasate 
greşit, atunci receptorul poate să le ignore. Deoarece aceste atribute sunt 
fundamentale pentru procesarea SOAP, le vom detalia în cele ce urmează. 


Atributul role 


Atributul ro controlează nodul SOAP (il vom numi nod-ţintă) care va putea 
procesa unul sau mai multe blocuri antet. Atributul ro% contine un URI care 
identifică rolul pe care îl va juca nodul-tinta. Atunci când un nod primește un 
mesaj incluzând blocuri antet, el trebuie să verifice aceste blocuri pentru a 
determina dacă există unul pe care-l poate prelucra. 

Desi unui atribut rok i se poate asocia orice URI, specificatia SOAP a 
prevăzut trei situații standard: 


— http:/ / ww w3.0r8/ 2002/06/ soap-envelope/ role/ none — in acest caz, nici un nod 
SOAP nu ar trebui să încerce să proceseze respectivul bloc antet, deși alte 
blocuri antet pot conţine referinţe la el și la conţinutul său; 

— http:/ /waw.w3.org/2002/06/ soap-envelope/ role/ next — in această circumstanta, 
fiecare nod trebuie să recunoască faptul că respectivul bloc antet trebuie 
trimis intact următorului nod SOAP (din cadrul rutei de transport a mesajului); 

— http:/ [ wmmm.mó3.org/ 2002/06 / soap-envelope/ role/ ultimateReceiver — in acest caz, blocu- 
rile antet ce contin atributul ro/e cu acest URI asociat (sau cele care nu au 
atributul ro% vor fi procesate doar de către destinatarul final. 


Ín exemplul dat mai sus, atributul ro% are ca valoare URI-ul //p:/ / www.w3.org/ 
2002/ 06 / soap-envelope/ role/ ultimateReceiver, ceea ce înseamnă cá destinatarul ultim 
este cel care va putea procesa acest antet. Acest ultim nod (pe care se gáseste 
mácar un setviciu Web), trebuie sá fie capabil sá proceseze continutul mesajului 
(inclus in elementul Body). 


Atributul mustUnderstand 


Dacă atributul mustUnderstand are valoarea true, atunci nodul care primeşte mesajul 
trebuie să-l poată procesa sau să emită un mesaj de eroare corespunzător în caz 
contrar. Blocurile antet care contin mustUnderstand-"true" sunt cunoscute 
sub numele de blocuri antet obligatorii. Anteturile care nu au specificat atributul 
mustUnderstand sunt totuşi examinate de nodurile-tinta. 
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În exemplul anterior atributul zzus/Understand are valoarea true, aceasta însemnând 
că destinatarul final este obligat să proceseze antetul. Altfel, nu poate să 
prelucreze corpul mesajului. 

În specificaţiile SOAP se precizează că un emițător SOAP nu trebuie să 
genereze un mesaj care să aibă atributul mustUnderstand cu valoarea 1 sau 0, ci 
true, respectiv, false. Totuşi, nodurile SOAP care primesc mesajul trebuie să 
accepte si mesajele pentru care atributul mustUnderstand are valoarea 0 sau 1. 


Atributul encodingStyle 


Atributul encodingStyle este folosit pentru a declara modul prin care conţinutul 
unui bloc antet a fost creat. Această informaţie permite nodurilor care inter- 
acționează cu acel mesaj să poată decodifica informaţiile pe care le conţine. 
SOAP permite mai multe scheme de codificare, dar furnizează și o schemă 
proprie. 

Deoarece acest atribut este utilizat și în corpul mesajului, vom discuta mai 
multe despre el în cadrul secțiunii 5.4. 


Atributul relay 


În SOAP 1.2, pentru blocurile antet este definit și atributul optional relay, cu 
valori de tip boolean. Acest atribut specifică dacă un bloc antet poate fi transmis 
mai departe, în cazul în care nodul intermediar care trebuia să-l proceseze nu a 
realizat acest lucru. Există precizată regula conform căreia un bloc antet care a 
fost deja prelucrat trebuie șters. 

Sunt situații în care proiectantul unui aplicații ar dori să introducă noi facilități 
în aplicație cu ajutorul unor blocuri antet. Un astfel de bloc antet va putea fi 
procesat de nodurile intermediare care îl ,,inteleg” si va fi ignorat de celelalte. În 
mod evident, facilitatea nou apărută nu a fost implementată de toate nodurile 
SOAP. Astfel, pentru a evita situațiile în care un nod SOAP nu recunoaște acel 
bloc antet și generează o eroare, se va preciza env:mustUnderstand="false". 
Suplimentar, pentru a împiedica aplicarea regulii implicite a mecanismului de 


procesare, blocul antet va avea asociat si atributul env:relay= "true" (blocul 
nu va fi eliminat). 
Exemplul următor prezintă utilizarea atributului re/ay: 


<?xml version="1.0" ?> 
<env:Envelope 
xmlns:env="http://www.w3.0rg/2003/05/soap-envelope"> 
<env:Header> 
<a: firstQuestion 
xmlns:a-"http://www.intrebare.ro" 
env:role-"http://www.intrebare.ro/Log" 
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env:mustUnderstand="true"> 


</a:firstQuestion> 
<b: secondQuestion 
xmlns:b="http://www.intrebare.ro" 
env:role-"http://www.w3.0rg/2003/05/ 
soap-envelope/role/next" 
env: relay="true"> 


</b:secondQuestion> 
«c:thirdQuestion 
xmlns:c-"http://www.intrebare.ro"» 


«/c:thirdQuestion» 
</env:Header> 
<env:Body>...</env:Body> 

</env:Envelope> 


Observăm în exemplul dat că blocul antet b-secondQuestion este ţintă pentru 
următorul (vex?) nod din calea de mesaje şi are prevăzut si atributul relay="true". 
Un nod SOAP care primeşte un asemenea mesaj poate procesa acest bloc antet 
în cazul în care îl poate înţelege, dar realizând aceasta conform regulilor existente, 
el va trebui să șteargă acest bloc antet înainte de a retransmite mesajul. Oricum, 
dacă nodul SOAP ignoră acest bloc antet (si poate efectua acest lucru, deoarece 
blocul nu trebuie obligatoriu să fie procesat), atunci el va trebui să-l retrimită. 

Procesarea blocului antet a-firstOuestion este obligatorie. În acest caz, blocul 
trebuie şters înainte ca mesajul să fie retransmis. Există si cazul de excepţie cand 
nodul, procesând și alte blocuri antet, găsește reguli care impun ca acel bloc să 
nu fie eliminat. 

Blocul antet e:thirdQuestion nu are prevăzut atributul re/zy, această situaţie fiind 
echivalentă cu relay="false". Conform regulilor, acest bloc antet nu este 
trimis mai departe dacă nu este procesat. 


Blocul antet Representation 


Blocul antet Representation permite mesajelor SOAP să transporte reprezentări ale 
resurselor Web. 

Utilizarea unui astfel de bloc se face în cazul în care receptorul are o 
capacitate limitată de a obţine reprezentări prin alte mijloace, de exemplu din 
cauza restricțiilor de accesare sau pentru că efortul de calcul ar fi prea mare 
(situaţie întâlnită, de pildă, pentru anumite dispozitive mobile). Acest bloc este, 
de asemenea, folositor atunci când sunt necesare mai multe referinţe la aceeași 
resursă, dar duplicarea resurselor nu este de dorit. 
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In acelasi mesaj SOAP pot exista mai multe aparitii ale blocului Representation. 
Să urmărim următorul exemplu:. 


<soap:Envelope 
xmlns:soap-'http://www.w3.0rg/2003/05/soap-envelope' 
xmlns:rep='http://www.w3.org/2004/08/representation' 


xmlns:xmlmime-'http://www.w3.0rg/2004/11/xmlmime'» 
<soap:Header> 
<rep:Representation resource= 
'http://www.infoiasi.ro/-adria/foto.jpg'» 


«rep:Data xmlmime:contentType- 
'image/jpg'»/aWKKapGGyQ-«/rep:Data» 
</rep:Representation> 
</soap:Header> 
<soap:Body> 
<a:Persoana 
xmlns:a-'http://www.infoiasi.ro/-adria/mystuff'» 
<a:nume>Alboaie Lenuta</a:nume> 
<a: foto 
uri='http://www.infoiasi.ro/~adria/me.jpg' /> 
</a:Persoana> 
</soap:Body> 
</soap:Envelope> 


Elementul Representation poate avea atributele resource si reinsert, conţinând 
obligatoriu marcatorul Dafa. Valoarea atributului resource identifică resursa Web a 
cărei reprezentare este transportată de elementul Representation. Atributul reinsert 
este de tip boolean. Când are valoarea /rze înseamnă că nodul intermediar care 
procesează mesajul trebuie să reinsereze blocul antet. Aceasta înseamnă că, în 
conjunctie cu atributul re/zy cu valoarea sve, blocul antet Representation trebuie 
retrimis. Dacă acest atribut nu există sau valoarea lui este fa/se, atunci se aplică 
regulile obișnuite de procesare SOAP. 

Valoarea elementului Data este o codificare în baza 64 (base64) a reprezentării 
unei resurse Web transportată de elementul Representation. 


5.4. Corpul mesajului SOAP. Elementul Body 


Elementul Body este un simplu container pentru datele XML destinate aplicaţiei. 
Dacă pentru Header trebuie respectate o serie de reguli, pentru Body nu există o 
formă standard a structurii sau o modalitate strictă de interpretare. Singura 
constrângere este ca destinatarul final (w/tmateRecipient) să poată procesa con- 
ţinutul mesajului. 
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Daca privim cu atenţie elementele Header si Body observăm că, desi sunt 
definite ca elemente independente, ele sunt totusi interconectate. Relatia dintre 
un bloc Body si unul Header este următoarea: o intrare Body este din punct de 
vedere semantic echivalentă cu una Header cate nu are specificat un atribut rok 
si pentru care atributul mustUnderstand prezintă valoarea true. 

Deja am furnizat exemple de continuturi stocate de marcatorul Body, astfel 
incat putem sa ne referim acum la semnalarea exceptiilor de comunicare. 


Coduri de eroare SOAP 


În afară de rolul său de a conţine datele destinate prelucrării de către o aplicaţie, 
Body este folosit si pentru trimiterea (către client, uzual) de excepţii care pot 
apărea în comunicarea de date. Astfel, este utilizat elementul Fau% pentru 
transportul informaţiilor (structurate sau nestructurate) legate de problemele 
cate pot apărea — de exemplu, în momentul procesării unui mesaj. Acest 
mecanism de management al erorilor este prevăzut de specificaţiile SOAP, de 
aceea instrumentele SOAP trebuie să respecte acest standard pentru tratarea 
erorilor. 

Elementul Fault are același spaţiu de nume ca Envelope şi contine obligatoriu 
două elemente-copil: Code si Reason. De asemenea, poate include optional și 
elementele Node, Rok și Detail. 

Un exemplu de utilizare a elementului Faz// il avem in fragmentul de cod de 
mai jos. Acest mesaj de eroare este un răspuns la mesajul din exemplul privitor 
la tranzacţiile de sortimente de portocale (a se revedea secțiunea 5.1). Pentru a 
înţelege ce a cauzat eroarea trebuie să cunoaștem semnificaţia fiecărui element 
prezent în mesaj. 


<?xml version="1.0" ?> 


<env: Envelope 
xmlns:env="http://www.w3.org/2002/06/soap-envelope" 
xmlns:p-"http://www.portocale.info/"» 
<env:Body> 
<env: Fault> 
<env : Code> 
<env:Value>env:Receiver</env:Value> 
<env : Subcode> 
<env:Value>p:cod_incorect</env:Value> 
</env : Subcode> 
</env:Code> 
<env:Reason lang="en-UK"> 
The specified product does not exist. 
</env:Reason> 
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<env:Detail> 
<err:DetaliiEroare xmlns:err= 
"http://www.portocale.info/fault"> 
<err:codAchizitInvalid> 
<p:cod>P10-01-GR</p:cod> 
</err:codAchizitInvalid> 
«/err:DetaliiEroare» 
</env:Detail> 
</env: Fault> 
</env:Body> 
</env:Envelope> 


Urmărind codul exemplului, remarcăm faptul că primul element al lui Faz/ 
este Code, incluzând două sub-elemente: primul este obligatoriu și se numește 
Value, iat al doilea e optional si are denumirea de Subcode. 

Elementul Value poate contine orice cod de eroare care se găsește în spaţiul 
de nume specificat de ///p:/ / wmw.m.org/ 2002/06 / soap-envelope. 

În cazul nostru, conţinutul marcatorului Valve este env:Receiver (vezi exemplul 
următor) si ne indica faptul cá a existat un nod la capătul rutei de mesaje (adică 
destinatarul final) care a generat eroarea. Astfel, putem sti cá aceastá eroare nu 
a fost generatá de un nod intermediar care a procesat antetul mesajului: 

«env:Code» 


<env:Value>env:Receiver</env:Value> 
</env:Code> 


Elementul Swbcode include elementul Value, care oferă informaţii despre erorile 
specifice aplicaţiei respective (se foloseşte spaţiul de nume definit de dezvoltatorul 
acelei aplicații). 

<env : Subcode> 


<env:Value>p:cod_incorect</env:Value> 
</env: Subcode> 


Tabelul următor enumără codurile de eroare definite de specificatia SOAP. 


Cod de eroare Descriere 


Version Mismatch Apare cand se sesizeaza o diferenta intre versiunile 
SOAP folosite. 


MustUnderstand Apare daca blocul antet continand atributul 
mustUnderstand-— true” nu a putut fi procesat de 
receptor. 
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Cod de eroare Descriere 


DataEncodingUnknown Apare atunci cand continutul fiecarui bloc antet 
sau bloc din corpul mesajului este codificat cu aju- 
torul unei scheme despre care nodul SOAP 
raportează că nu o poate înțelege. 


Sender Apare atunci când emițătorul trimite un mesaj care 
nu are un format corect (de exemplu, un mesaj 
care nu conține suficiente date astfel încât destina- 
tarul să-l poată procesa). 


Receiver Apare atunci când entitatea ce recepționează mesa- 
jul nu-l poate procesa din cauza unor eroti ale 


aplicaţiei. Presupunându-se că eroarea nu este per- 
sistentă, mesajul se poate retransmite. 


Server Clasa de erori Server precizează că mesajul nu poate 
fi prelucrat, nu din motive legate strict de conti- 
nutul mesajului, ci mai degrabă din cauza unor pro- 
bleme de procesare. De exemplu, serviciul ar putea 
include o conexiune la un tert server care nu rás- 
punde. Mesajul at putea fi totuşi procesat cu succes 
într-un alt moment de timp. 


Desi nu-l găsim în exemplul nostru, elementul Swbcode determină ca meca- 
nismul de tratare a erorilor în SOAP să fie extensibil. Astfel, Code conţine un 
sub-element obligatoriu Va/ve si unul optional Subcode, care poate la rândul lui să 
includă alte marcaje Subcode. 

Elementul Reason asociat lui Code este utilizat pentru a furniza o explicaţie în 
limbaj natural. În exemplul nostru, avem un mesaj emis în limba engleză: „The 
specified product does not exist” („Produsul specificat nu există”). Instrumentele 
SOAP folosesc adesea conţinutul elementului Reason atunci când semnalează 
erori, astfel încât activitatea de depanare să decurgă mai ușor. 

Elementul optional Node furnizează informaţia despre nodul din calea de 
mesaje care a generat eroarea. Conţinutul marcatorului Node va fi URI-ul acelui nod. 
În exemplul de mai sus nu există specificat Node, deoarece entitatea care a generat 
eroarea a fost ultimul destinatar si, evident, emițătorul cunoaște URI-ul său. 

Elementul Node este completat de marcatorul optional Rok, care furnizează 
informaţii despre ceea ce realiza nodul atunci când a eșuat. Conţinutul ele- 
mentului Ro/ este de obicei un URI identificând operaţia (de obicei, un serviciu 
Web) cauzatoare a erorii. Partea responsabilă cu rezolvarea erorilor poate 
determina ce ,,portiune” a aplicaţiei a funcționat greșit. Putem observa, deci, că 
elementele Node si Ro% sunt utile pentru detectarea cu ușurință a erorilor care 
pot apărea. 


108 SERVICII WEB 


Să urmărim în exemplul următor elementul De/a// in forma specifica a unei 
aplicaţii. 
<env:Detail> 
«err:DetaliiEroare 


xmlns:err-"http://www.portocale.info/fault"» 
<err:codAchizitInvalid> 
<p:cod>P10-01-GR</p:cod> 
</err:codAchizitInvalid> 
«/err:DetaliiEroare» 
</env:Detail> 


Prezenţa marcatorului Defai/ furnizează informaţii despre erorile survenite 
atunci când destinatarul final a încercat procesarea corpului mesajului. Este 
evident că — atunci când elementul De/a// există — elementele Node si Ro/e nu vor 
mai fi specificate. Același lucru este valabil și invers. 

Conţinutul elementului De/a// este dependent de specificul fiecărei aplicaţii in 
parte. 


5.5. Maniera de codificare a mesajelor — SOAP Encoding 


Deși scopul acestei cărți nu este de a intra în detalii legate de modelul de date 
utilizat de protocolul SOAP sau de alte scheme de serializare, vom prezenta în 
secțiunile următoare câteva concepte care să ajute cititorul să aprofundeze 
specificaţiile oficiale legate de codificări. 


Termeni folosiți în procesul de codificare 


Pentru o mai bună înţelegere a procesului de codificare în maniera SOAP a 
datelor transportate, este importantă clarificarea următorilor termeni. 

Termenul de valoare (value) este folosit pentru a descrie o anumită dată 
codificată cu ajutorul unui element XML. O dată reprezintă un șir de caractere. 
Valorile dintr-un mesaj SOAP aparţin întotdeauna unui anumit tip de date 
(similar variabilelor dintr-un limbaj de programare ca Java ori C). 

SOAP face distincţie între valorile simple (simple value) si valorile compuse 
(compound value). 

Tipurile sample value nu au elemente componente. Pentru a înţelege ce sunt si 
cum arată aceste valori simple, să urmărim un paralelism între tipurile 777, float si 
string, aşa cum sunt reprezentate într-un limbaj de programare (eg, Java), si 
modul de reprezentare al lor în SOAP: 
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int cantit = 33; 

<cantit xsi:type="xsd:int">33</cantit> 

float pi = 3.14159265; 

«pi xsi:type="xsd: float">3.14159265</pi> 
java.lang.String sortim = "verde"; 

<sortim xsi:type="xsd:string">verde</sortim> 


Se poate remarca faptul că tipurile de date SOAP sunt de fapt cele specificate 
de recomandarea XML Schema a Consottiului Web. 

Pentru cazul compound value, o valoare e constituită din mai multe elemente 
componente între care există o relaţie. Elementele componente care formează o 
astfel de valoare compusă pot fi accesate prin diverse metode precum: indicarea 
poziţiei în secvenţa de valori (să ne imaginăm cum accesăm un element pe baza 
indexului, atunci când folosim un tablou), utilizând o cheie (ca în cazul tablourilor 
asociative — hash fables) sau recurgând la numele elementului respectiv (similar 
structurilor din C). Un astfel de mecanism este cunoscut sub numele de accesor 
(accessor). 

Un exemplu în care se folosesc valori compuse (vom face din nou o paralelă 
cu anumite tipuri de date din Java) este următorul: 


int[3] Stoc = (10, 74, 33}; // tablou de numere 


<Stoc xsi:type="SOAP-ENC:Array" 
SOAP-ENC: arrayType="xsd:int[3]"> 
<val>10</val> 
<val>74</val> 
<val>33</val> 
</Stoc> 


class Produs // o clasă cu doi membri-dată 


{ 
public int cantit = 33; 


public java.lang.String sortim = "Portocale"; 
} 
Produs produs = new Produs(); 
<Produs> 


<cantit xsi:type="xsd:int">33</cantit> 
<sortim xsi:type="xsd:string">Portocale</sortim> 
</Produs> 


In acest exemplu, sunt folositi accesori ordinali pentru obtinerea valorilor din 
variabila de tip tablou Szoc. 
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Cat priveste obiectul Java produs, pentru a obtine elementele lui componente 
vom folosi accesori cu nume: cantit si sortim. Vom reveni ulterior la discuţia 
asupra tipurilor compuse (inclusiv tablouri si structuri). 

In SOAP, ca in majoritatea limbajelor de programare, valorile au asociat un 
anumit tip de dată. Asa cum se observa si din exemplu, mai întâi declarăm 
instante ale tipurilor și mai apoi le atasám o anumită valoare. 

În esenţă, un accesor reprezintă un element care conţine sau permite accesul 
la o valoare. În exemplul următor, prenume este un accesot, iar Ory este o valoare: 


| <prenume>Ory</prenume> 


In codul XML de mai jos avem specificat un tip compus reprezentand o 
combinaţie de doi accesori (ze şi prenume) care sunt copiii unui singur accesor 
(identitate). 

<identitate> 

<nume>Blue</nume> 


<prenume>Ory</prenume> 
</identitate> 


Prin intermediul atributelor 7d si href, SOAP definește accesori de tip single- 
-referenced sau multi-referenced. Un accesor simplu-referentiat (single-referenced) nu 
poseda o identitate, exceptand cazul in care este element-copil al altui element. 
In exemplul următor, <adresa> reprezintă un accesor de tip single-referenced: 

<persoana> 

<identitate nume="Blue Ory"> 
<adresa> 
<strada>Portocalelor</strada> 
<localit>Iasi</localit> 
<tara>Romania</tara> 
</adresa> 

</identitate> 

</persoana> 


Conform specificatiilor SOAP, elementelor li se permite sa referentieze valorile 
conţinute în alte elemente. În acest caz, elementul are asociat un atribut (¿d care 
identifică elementul în cadrul căruia se află data referentiata. 

Această posibilitate de a referentia valorile altor elemente este importantă din 
mai multe motive. În primul rând, există şansa ca dimensiunea mesajului să se 
micsoreze. Să ne imaginăm că avem de trimis un mesaj care contine toti membrii 
familiei Be. Documentul XML în cauză ar putea avea o structură precum 


următoarea: 
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<membru> 
<prenume>Ory</prenume> 
<nume>Blue</nume> 

</membru> 

<membru> 
<prenume>Grappy</prenume> 
<nume>Blue</nume> 

</membru> 

<membru> 
<prenume>Kiwy</prenume> 
<nume>Blue</nume> 

</membru> 


Dupa cum se poate observa, are loc o duplicare nedorita a datelor. 
Referintele ne permit minimizarea repetitiilor, deoarece multi accesori pot 
referi un acelasi element. Cand are loc acest lucru, valoarea este de tip 
multi-referinta (wulti-referenced). 

Folosind aceasta facilitate, noul document XML va avea forma: 


<nume-fam id="nume-fam">Blue</nume-fam> 

<membru> 
<prenume>Ory</prenume> 
<nume href="#nume-fam" /> 

</membru> 

<membru> 
<prenume>Grappy</prenume> 
<nume href="#nume-fam" /> 

</membru> 

<membru> 
<prenume>Kiwy</prenume> 
<nume href="#nume-fam" /> 

</membru> 


Chiar dacă în exemplul de fata nu s-a salvat foarte mult spaţiu, să ne gândim 
la utilitatea acestui mecanism atunci când lucrăm, de exemplu, cu o multitudine 
de elemente compuse. 

Variabilele multi-referintá sunt utile si atunci când se serializează un graf sau 
o colecţie de obiecte, multe dintre acestea având referinţă către același obiect. În 
acest caz, este important să menţinem legăturile astfel încât să putem reconstrui 
obiectul la deserializare. 

Aceasta abordare poate fi folosita, de asemenea, pentru a permite unui 
accesor sa teferentieze informaţii externe resurselor, care nu fac parte din 
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elementul Envelope (date binare, de exemplu). În exemplul următor sunt referite 
informații conținute în interiorul unui document XML extern: 
<identitate nume='Blue Grappy'> 
<adresa 
href='http://www.portocale.info/inf.xml#BlueGrappy' 
/> 
</identitate> 


Tipuri de date 


După cum probabil deja cititorii avizati au remarcat, tipurile de date suportate de 
codificarea SOAP sunt definite în specificațiile XML Schema: Datatypes (a se 
revedea capitolul 2). 

Pot fi folosite tipurile elementare ca int, float, string, enumerări, şiruri de octeți 
etc., plus tipurile derivate din acestea. 


byte 


http://schemas.xmlsoap.org/soap/encoding/ 


integer 
integer 
http://schemas .xmlsoap.org/soap/encoding/ 


ENTITY 
ENTITY 


http://schemas.xmlsoap,org/soap/encoding/ 


ID 
ID 
http://schemas.xmlsoap.org/soap/encoding/ 


Figura 6. Fragment din reprezentarea grafică a schemei privitoare 


la codificare (SOAP Encoding) 


Vom face mai jos o trecere rapidă în revistă a acestor tipuri, lăsând la 
latitudinea cititorului aprofundarea amănuntelor. 
° String 


Tipul de date string este definit de recomandarea XML Schema. De remarcat că 
acest tip s7ring nu este identic cu tipul spe întâlnit in alte limbaje de programare. 
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In mod particular, interzice aparitia unei serii de caractere pe care acele limbaje 
le permit (sunt caracterele rezervate din XML, precum ,,<”, „>” ori ,,&”). Un 
string poate fi codificat ca single-referenced sau multiple-referenced. 

În exemplul de mai jos, ,,Portocale cu blană” reprezintă o valoare elementară. 


| <string>Portocale cu blană</string> 


* Enumerare 


Specificatia XML Schema: Datatypes defineşte un mecanism numit enumerare 
(enumeration). Modelul SOAP îl adoptă în mod direct. Limbajele de programare 
definesc tipul enumerare într-un mod diferit. În cazul SOAP, enumeration — luat 
drept concept — indică un set distinct de nume. O enumerare particulară 
reprezintă o listă de valori distincte, apropiate, bazate pe același tip. De exemplu, 
(,1”, 3”, ,5") este o enumerare posibilă bazată pe tipul zz/eger. Sunt suportate 
enumerarile pentru toate tipurile simple, exceptând tipul boolean. 

Fie următoarea schemă — reprezentarea grafică a acesteia este dată în figura 7: 


<xs: schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> 
<xs:element name-"lotPortocale" type="xs:int" /> 
<xs:element name-"greutate" type-"xs:float" /> 
<xs:element name="culoare"> 
<xs:simpleType> 
<xs:restriction base="xs:string"> 
<xs:enumeration value="Oranj" /> 
<xs:enumeration value="Galben" /> 
<xs:enumeration value-"Albastru" /> 
«/xs:restriction» 
</xs:simpleType> 
</xs:element> 
</xs:schema> 


lotPortocale 
| culoare | E [x] restricts: xs:string E 


Figura 7. Reprezentarea grafică a schemei XML specificând o enumerare de elemente 
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O posibilă instanţă care se conformează schemei XML anterioare poate avea 
forma: 
<lotPortocale>12</lotPortocale> 


<greutate>3374.01</greutate> 
<culoare>Albastru</culoare> 


e Sir de octeți 


Desi în multe limbaje de programare sirurile de caractere (57772) sunt privite ca 
fiind şiruri de octeți, în SOAP lucrurile stau diferit. Un string este reprezentat cu 
ajutorului tipului de dată string. Astfel, dacă aveţi la dispoziţie o colecţie de octeți 
care nu reprezintă un string (de exemplu, conţinutul binar al unei imagini oti al 
unui fișier executabil), atunci acești octeți trebuie transformați cu algoritmul de 
codificare base64 descris în specificatia XML Schema. 

Un exemplu de codificare base64 a unui sit de octeti este urmatorul: 


<imagine xsi:type="SOAP-ENC:base64"> 
hsgajTYUTUgsjaguuwgqljgds33ds 
</imagine> 


Un sir de octeți poate fi codificat ca o valoare de tip singl-referenced sau 
multi-referenced. Regulile de codificare pentru siruri de octeti sunt similare cu cele 
pentru string. 

In particular, un element sir de octeți poate avea un atribut de tip id. 
Elementele accesor suplimentare pot avea asociat atributul Pref. 


* Folosirea tipurilor compuse 


SOAP definește tipuri corespunzătoare a două modele întâlnite adesea în 
limbajele de programare. 

Primul este séructura. Un struct este o valoare compusă în care numele 
accesorului permite diferenţierea valorilor membrilor si nici un accesor nu are 
același nume cu un altul (se asigură unicitatea numelor). 

Al doilea procedeu recurge la un zablou, un array permite memorarea unei 
valori compuse în care indexul (numărul) poziţiei diferențiază valorile membrilor 
sal. 

Un exemplu in care se folosesc structuri este urmatorul, considerand frag- 
mentul de schema XML: 

<xs:element xmlns:xs='http://www.w3.org/2001/XMLSchema' 

name="Carte"> 
<xs:complexType> 


<xs : sequence> 
<xs:element name="autor" type="xs:string" /> 
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<xs:element name="titlu" type="xs:string" /> 
<xs:element name="pag" type="xs:integer" /> 
</xs:sequence> 
</xs:complexType> 
</xs:element> 


Reprezentarea grafică este ilustrată de figura 8. 


integer 
pag 
Figura 8. Reprezentarea grafică a schemei XML specificând o structură 


O structură ce se conformează schemei anterioare poate fi următoarea: 


«Carte xmlns-"urn:infoiasi.ro"» 
<autor>Sabin Buraga</autor> 
<titlu>Proiectarea siturilor Web</titlu> 
<pag>346</pag> 

</Carte> 


În cazul tablourilor exemplificăm cu ajutorul schemei de mai jos, care foloseşte 
în mod explicit maniera de codificare SOAP: 


<xs: schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
xmins:enc="http://www.w3.org/2001/06/soap-encoding"> 
«xs:import 

namespace-"http://www.w3.0rg/2001/06/soap-encoding" 
/> 
<xs:element name="numereleFavorite" 
type="enc:Array" /> 
</xs:schema> 


Un exemplu de tablou conform schemei de mai sus este: 


<numereleFavorite 
xmlns:xs-"http://www.w3.org/2001/XMLSchema" 
xmlns:enc-"http://www.w3.org/2001/06/soap-encoding" 
nc:itemType-"xs:int" enc:arraySize="2"> 
<number>29</number> 
<number>10</number> 
</numereleFavorite> 
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5.6. Reguli de serializare 


Elementele XML într-un mesaj SOAP sunt fie independente, fie imbricate. Din 
însăși natura XML, majoritatea elementelor sunt imbricate ca sub-elemente ale 
altora. Marcajele independente nu sunt sub-elemente ale nici unui element, iar în 
urma serializării ele se găsesc pe primul nivel al arborelui DOM asociat. 

Toate valorile într-un mesaj SOAP sunt codificate și incluse în cadrul unui 
element. Aceasta nu înseamnă că orice element XML conţine o valoare. De 
exemplu, tipurile de date compuse precum structurile sau tablourile includ 
sub-elemente conţinând valori. 


Modelul de date SOAP 


Atributul encodingStyle apare atât în blocurile antet, cât si în cadrul elementului 
Body al unui mesaj SOAP. Acest atribut impune ca mesajul să aibă o anumită 
formă care se supune regulilor unei scheme XML ce este cunoscută atât de 
emițător, cât si de receptor. 

Din anumite motive, poate exista și riscul ca emițătorul și receptorul să nu 
aibă acces la aceeași schemă. Pentru evitarea problemelor de acest gen, spe- 
cificatiile SOAP prevăd existenţa unei scheme si a unor reguli de codificare 
proprii. Acestea sunt cunoscute sub denumirea de SOAP Encoding și spaţiul de 
nume corespunzător se precizează prin construcția: 


env:encodingStyle= 
"http://www.w3.org/2003/05/soap-encoding" 


Regulile pentru codificarea datelor aplicaţiei în mesaje SOAP se regăsesc in 
recomandarea SOAP sub denumirea de model de date (SOAP Data Model). În 
această parte a specificaţiei se arată cum sunt reduse structurile de date la un graf 
etichetat. 

Mecanismul general este prezentat în figura 9. 

Există două aspecte ale codificării. Primul constă în transformarea structurilor 
de date într-o formă convenabilă de exprimare în XML, cu ajutorul regulilor 
specificate în modelul de date SOAP. Un alt aspect presupune verificarea datelor 
existente în documentul XML, astfel încât să respecte regulile din schema SOAP. 

În mod obişnuit, instrumentele SOAP vor suporta serializarea si deserializarea 
grafurilor de obiecte folosind acest model, cu minim de efort din partea 
programatorului. 
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<env:Body> 


</env:Body> 


pbojfivdpapoua dVOS 


<xs:schema> 


</xs:schema> 


Document 
XML Schema 


Figura 9. Mecanismul de codificare oferit de SOAP 


Utilizarea altor codificări SOAP 


Multe dintre aplicaţiile existente au fost create astfel încât să poată folosi XML. 
Dacă se dorește utilizarea protocolului SOAP în cadrul acestor aplicaţii, ar trebui 
să se recurgă la schemele de modelare deja existente. 

Aceasta se poate realiza prin intermediul atributului encodingStyle. Deci, in loc 
să se codifice corpul sau antetul unui mesaj folosindu-se SOAP Data Model, se 
vor putea utiliza regulile din schemele de validare specifice fiecărei aplicaţii. 
Evident, trebuie să ne asigurăm că entitatea care dorește serviciile pe care le 
oferim înţelege modul nostru de codificare. 

Un asemenea stil de codificare adaugă un plus de forță protocolului SOAP. 
Cu excepţia faptului că acest mod de codificare favorizează reutilizarea schemelor 
deja existente și, mai mult, se are de-a face cu schimburi de mesaje și nu cu 
apeluri de proceduri la distanță (RPO), se încurajează proiectarea de servicii Web 
care permit o granularitate mult mai mare a interacțiunilor. În esenţă, se face 
trecerea de la modelul RPC — care încurajează un model de tip fine-grain (un 
client trimite o serie de date, apoi primește alte date și comunicarea continuă 
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pana cand clientul este satisfacut) — la un model coarser-grained (clientul transmite 
toate datele necesare, astfel încât receptorul, dupa ce realizează operaţiile 
preconizate, va trimite după un anumit timp răspunsul complet). 

Pentru a înţelege mai bine această trecere de la fine-grained la coarser-grained, să 
ne imaginăm diferența dintre o discuţie la telefon și trimiterea unui fax. În 
primul caz, purtăm un dialog, în care partenerii joacă un anumit rol, schimbând 
pe o anumită perioadă de timp tot felul de informaţii. În al doilea caz însă, 
cineva care doreşte să rezolve o problemă trimite un fax prin intermediul căruia 
transmite toate informaţiile de care cealaltă parte are nevoie. 

Am făcut mai sus precizarea că, folosind propriile noastre scheme de 
codificare, trebuie să scriem și propriul cod cu ajutorul căruia să se poată realiza 
managementul mesajelor codificate în acest mod. Dacă un anumit nod folosește 
SOAP RPC (unde codificarea este dată de modelul de date SOAP) si dorim să 
comunicăm cu acel nod, atunci trebuie să efectuăm o adaptare a instrumentelor 
noastre în acest sens. 


Schemă XML 


Schemă SOAP def. de utiliz. 


<xs:schema> <xs:schema> 


</xs:schema> — a 


Figura 10. Procesarea datelor folosind mai multe scheme 


După cum se remarcă in figura 10, handler-ul aflat pe serverul SOAP este cel 
care oferă posibilitatea de înţelegere a mesajelor care sunt codificate cu o altă 
schemă, diferită de cea implicită, pusă la dispoziţie de protocolul SOAP. 
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6. Maniera de transport al mesajelor SOAP 


Asa cum precizam la inceputul capitolului de fata, in cadrul stivei tehnologiilor 
care stau la baza serviciilor Web, SOAP se regăsește la un nivel superior 
nivelurilor de reţea si transport ale Internetului. Pentru aplicaţiile folosind 
SOAP, nu contează ce protocol de transport este utilizat la realizarea schimbului 
de mesaje. Acest aspect conferă protocolului SOAP o flexibilitate sporită. 

În cadrul specificaţiile SOAP întâlnim expresia SOAP Binding, care precizează 
modul prin care mesajele SOAP pot fi transmise de la un nod la altul, folosind 
la bază un anumit protocol (HTTP, SMTP etc.). 

Un mesaj SOAP e definit respectând regulile XML Infoset. Pentru transportul 
unui astfel de document, se recurge la un protocol care să permită forma serializată 
a documentului si care să faciliteze transportul între nodurile din ruta (calea) de 
mesaje fără pierdere de informaţii — se asigură fiabilitatea transmisiei de date. 

În majoritatea situaţiilor se pot utiliza facilităţile native ale protocolului de 
bază sau, după caz, se pot introduce anumite blocuri antet care să ofere 
functionalitatile de care este nevoie. 


6.1. Relatia dintre SOAP si HTTP 


Legătura SOAP-HTTP oferă avantajul de a folosi caracteristicile protocolului 
SOAP împreună cu bogatele trăsături oferite de HTTP. Transportând mesajele 
SOAP via HTTP nu înseamnă că protocolul SOAP suprascrie semantica existentă 
a HTTP-ului, ci, mai degrabă, faptul că semantica SOAP se integrează in mod 
natural în cea a protocolului HTTP. 

SOAP, în mod firesc, urmează modelul HTTP cerere /răspuns, cererea SOAP 
încapsulându-și parametrii în cererea HTTP, iar furnizarea răspunsului SOAP se 
realizează printr-un răspuns HTTP. 


HTTP POST (cerere SOAP) 


răspuns HTTP (răspuns SOAP) 


Figura 11. Încapsularea mesajelor SOAP în cadrul mesajelor HTTP 
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De observat ca intermediarii SOAP nu sunt aceeasi cu intermediarii HTTP. 
Astfel, un intermediar HTTP adresat cu un câmp din antetul unui mesaj HTTP 
nu poate controla și prelucra elementul de conţinut al mesajului SOAP transportat 
în cererea HTTP. 

Există două modalități de schimb al mesajelor SOAP folosind HTTP, denu- 
mite si sabloane de interschimb al mesajelor — MEP (Message Exchange Pattern): 


* utilizând metoda POST pentru transportul mesajelor SOAP în corpul cererii 
HTTP, respectiv în mesajul de răspuns (acesta este modelul de schimb al 
mesajelor SOAP de tip cerere-răspuns — SOAP Request-Response Message Exchange 
Pattern); 

* utilizând metoda GET pentru a întoarce mesajul SOAP in corpul mesajului 
de răspuns HTTP (acesta este modelul de schimb al mesajelor SOAP de tip 
răspuns — SOAP Response Message Exchange Pattern). 


Ar putea aparea intrebarea: care metoda ar trebui folosita la un moment dat? 
Conform modelului arhitectural al spatiului Web, metoda GET poate fi folosita 
atunci cand scopul schimbului de mesaje este de obtinere a unei informatii, iar 
resursa cu care s-a interactionat a rămas neschimbată. Astfel de interacțiuni sunt 
cunoscute în specificaţiile HTTP ca fiind sigure (safe) şi idempotente. Metoda 
POST poate fi folosită în toate cazurile. 


Relatia SOAP — HTTP GET 


Utilizarea metodei GET semnifică faptul că răspunsul la cererea GET a unui 
nod SOAP este un mesaj SOAP încorporat în răspunsul HTTP. 

Să urmărim exemplul următor în care avem o cerere GET (după cum se 
observă, parametrii de intrare transmisi serviciului Web sunt incluși in URL, ca 
sir de interogare — query string — prefixat de ,,?”’): 

GET /Informatii?tip=3307 HTTP/1.1 


Host: www.portocale.info 
Accept: application/soaptxml 


Facem observaţia că in acest caz corpul mesajului e vid (empty body). 

Câmpul de antet Accept este folosit pentru a indica formatul preferat cores- 
punzător cererii realizate. În cazul nostru, este tipul MIME  application/ soap xul, 
datele fiind procesate de aplicaţia client — in loc de tipul ¢ext/Atm/ folosit pentru 
redarea continutul in cadrul navigatorului (deci datele in loc sa fie destinate 
„consumului” uman vor fi utilizate pentru o anumită procesare de către o 
aplicaţie la nivelul masinii-client). 
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Răspunsul cererii GET de mai sus va putea fi următorul: 


HTTP/1.1 200 OK 
Content-Type: application/soapt+xml; charset="utf-8" 
Content-Length: NNNN 


<?xml version='1.0' ?> 

<env: Envelope 
xmins:env="http://www.w3.org/2002/12/soap-envelope"> 

<env:Header> 


</env:Header> 
<env:Body> 
<!-- diferite informații specifice aplicaţiei ==> 
</env:Body> 
</env:Envelope> 


Relatia SOAP — HTTP POST 


Dupa cum am precizat anterior, POST este disponibila pentru toate aplicatiile, 
indiferent daca se „scufundă” date XML în mesajele SOAP sau se utilizează 
stilul SOAP RPC. 

Vom considera mai jos un exemplu in care o cerere SOAP, numită GetOrangePrice, 
este trimisă serverului. Cererea are un parametru cu numele OrangeType, iar răspunsul 
va întoarce un parametru Pre. Spaţiul de nume propriu aplicaţiei (în fapt, al 
serviciului Web) ce va fi invocate pe server este ///p:/ / ww. portocale.înfo/ . După cum 
se poate deduce, dorim să obținem preţul unui anumit sortiment de portocale. 

Cererea SOAP va avea structura: 

POST /Inf HTTP/1.1 

Host: www.portocale.info 


Content-Type: application/soapt+xml; charset="utf-8" 
Content-Length: NNNN 


<?xml version="1.0"?> 
<soap:Envelope 
xmlns:soap-"http://www.w3.0rg/2001/12/soap-envelope" 
soap:encodingStyle= 
"http://www.w3.org/2001/12/soap-encoding"» 
«soap:Body xmlns:p="http://www.portocale.info/"> 
<p:GetOrangePrice> 
<p:OrangeType>Portocale grecesti 
fără coajá«/p:OrangeType» 


</p:GetOrangePrice> 
</soap:Body> 
</soap:Envelope> 


122 SERVICIL WEB 


Raspunsul SOAP, incapsulat intr-un mesaj HTTP, este de forma: 


HTTP/1.1 200 OK 
Content-Type: application/soapt+xml; charset="utf-8" 
Content-Length: NNNN 


<?xml version="1.0"?> 

<soap:Envelope 
xmlns:soap-"http://www.w3.0rg/2001/12/soap-envelope" 
Soap:encodingStyle- 


http://www.w3.org/2001/12/soap-encoding"» 
«soap:Body xmlns:p="http://www.portocale.info/"> 


<p:GetOrangePriceResponse> 
<p: Price>33</p:Price> 
</p:GetOrangePriceResponse> 
</soap:Body> 
</soap:Envelope> 


In cazul în care apare o eroare la procesarea cererii, se va returna un mesaj 


SOAP Fault de genul: 


HTTP/1.1 500 Internal Server Error 
Content-Type: application/soaptxml; charset="utf-8" 
Content-Length: NNNN 


<?xml version='1.0' ?> 
<env: Envelope 


xmins:env="http://www.w3.org/2002/12/soap-envelope"> 
<env:Body> 
<env: Fault> 


</env:Fault> 
</env:Body> 
</env:Envelope> 


6.2. Relatia dintre SOAP si transportul de mesaje 
de posta electronica (e-mail) 


Mesajele SOAP pot fi trimise ca parte text a corpului unui mesaj de e-mail sau 
drept fișier atașat (attachment) acestui mesaj. 

Facem încă de la început observaţia că exemplele oferite mai jos nu reprezintă 
o manieră standard, ci doar o modalitate de transport al mesajelor SOAP. 

Să urmărim următoarea cerere SOAP transportată cu ajutorul protocolului 


SMTP (Simple Mail Transfer Protocol): 
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From: admin@axiologic.ro 

To: admin@portocale.info 

Subject: Contract 

Date: Fri, 29 Dec 2006 18:33:00 EST 
Message-Id: <M56721-9MGHGJS5757@axiologic.ro> 
Content-Type: application/soap+xml 


<?xml version='1.0' ?> 
<env: Envelope 
xmlns:env-"http://www.w3.0rg/2003/05/soap-envelope"» 
<env:Header> 
<p:contract 
xmlns:p="http://www.portocale.info/contracts" 
env: role= 
"http://www.w3.0rg/2003/05/soap-envelope/role/next" 
env:mustUnderstand-"true"» 
<p:reference> 
uuid:A292310-S238787-S398298 
</reference> 
<p:dateAndTime> 
2006-12-29T18:33:00.000-05:00 
</p:dateAndTime> 
</p:contract> 


</env:Header> 
<env: Body> 


</env:Body> 
</env:Envelope> 


Vom presupune ca nodul care receptioneaza un astfel de mesaj are abilitatea 
de a procesa mesajele SOAP. In plus, si nodul care a emis cererea trebuie să aibă 
capacitatea de a putea prelucra, de exemplu, un răspuns SOAP, în cazul apariţiei 
unei erori. 

Răspunsul pentru cererea anterioară ar putea fi de forma: 


From: admin@portocale.info 

To: admin@axiologic.ro 

Subject: ContractAx 

Date: Fri, 29 Dec 2006 18:45:07 EST 
Message-Id: <CPAX6786382A@portocale.info> 
In-replyto: <M56721-9MGHGJS5757@axiologic.ro> 
Content-Type: application/soap+xml 

<?xml version='1.0' ?> 


<env: Envelope 
xmlns:env-"http://www.w3.0rg/2003/05/soap-envelope"» 
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<env:Header> 
<p:contract 
xmlns:p-"http://www.portocale.info/contracts" 
env:role- 
"http://www.w3.0rg/2003/05/soap-envelope/role/next" 
env:mustUnderstand="true"> 


<p:reference> 
uuid:A292310-S238787-S398298 
</p:reference> 
<p: dateAndTime> 
2006-12-29T18:45:07.000-05:00 
</p:dateAndTime> 
</p:contract> 


</env:Header> 
<env :Body> 


«/env:Body» 
</env:Envelope> 


In acest exemplu, Message-ID-ul corespunzător mesajului original este 
transportat in In-replyto, care interconectează mesajele de e-mail la nivelul 
SMTP. Nu se furnizează însă o corelație specifică SOAP între cerere si 
răspunsul aferent. În exemplificarea de faţă, aceasta se bazează pe existența 
blocului antet contract. În general, aceste corelaţii sunt dependente de fiecare 
aplicaţie în parte. 

Mai multe discuţii legate de legătura SOAP-Emai/ puteţi găsi la adresa 
http:/ / www.w3.org/ TR/ soap 2-email. 


7. Apelul de proceduri la distanta via SOAP RPC 


Datorită faptului că specificaţiile SOAP furnizează suport pentru RPC, multi 
programatori au constatat ușurința cu care se pot dezvolta servicii Web bazate 
pe SOAP RPC. Chiar dacă SOAP RPC nu este paradigma cea mai dominantă 
pentru SOAP, este uşor de obţinut rezultate folosind-o, deoarece majoritatea 
instrumentelor suportă bine-cunoscutul model RPC. 

Avem în figura de mai jos arhitectura generală SOAP-RPC: 
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Client 
apel local de proc. 


Proced. 
ciot (stub) 


| 


Sistem SOAP 


Codificare 
XML 


Impachetare 


RPC, CORBA, COM,... 


Legare (binding) 


Internet 


(eventual, 


intermediari) 


Mesaj SOAP ___. 


Server 


apel local de proc. 


Proced. 
ciot (stub) 


| 


Sistem SOAP 


Figura 12. Mecanismul de transmisie si invocare SOAP RPC 


SOAP RPC trebuie să cunoaștem următoarele: 


mesajului SOAP. 


adresa nodului SOAP ţintă; 
numele metodei (procedurii) dorite a fi invocate; 


orice parametri de ieșire sau valori de retur; 


Conform specificaţiilor SOAP, atunci când dorim să realizăm o cerere folosind 


argumentele (si valorile acestora) care vor fi transmise metodei împreună cu 


modalitatea clară de separare a argumentelor folosite pentru identificarea 
resursei Web de cele utilizate de către nodul-tintá care face apelul metodei. 


Opţional, putem avea date care pot fi transportate în blocurile antet ale 


Unul din principalele scopuri ale protocolului SOAP este cel de a încapsula 


si interschimba apelurile RPC folosind extensibilitatea si flexibilitatea limbajului 


XML. 
SOAP RPC implică două modalități de interschimb al mesajelor: SOAP 


Response MEP şi SOAP Reguest-Response MEP, despre care am discutat în cadrul 


secțiunii 6.1 a prezentului capitol. 
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Să urmărim in cele de mai jos un exemplu de utilizare a SOAP-RPC. Figura 
13 prezintă o interacțiune simplă între un serviciu Web care oferă posibilitatea 
de deschidere a unui cont bancar și un client (în cazul nostru, compania 
Axiologic Research) care intenționează să folosească acest serviciu. Serviciul 
Web pune la dispoziţie o operaţie (metodă) numită deschideCont(...), fiind expus 
via un server SOAP. Maniera de acces la acest serviciu Web se realizează prin 
SOAP RPC (protocolul SOAP nu furnizează nici o modalitate de descriere a 
interfetelor, dar — asa cum s-a văzut în capitolul 3 — acest aspect e suplinit de 
limbajul WSDL). 


cerere SOAP RPC 
apel deschideCont(...) 


Aplic. 
client 


răspuns SOAP RPC (nrCont) 


// Implementarea clientului // Implementarea serviciului 

Banca b = new Banca(); class Banca { 

String cont = b.deschideCont public String deschideCont 
(tip, denumire, sitWeb); (tip, denumire, sitWeb) | 


// operaţii pt. crearea 
// unui cont bancar 
return nrCont; 


}} 
Figura 13. Interactiunea cu un serviciu Web folosind SOAP RPC 


Clientul interacționează cu serviciul printr-o clasă ciot (numită s/ub sau proxy) 
purtând numele de Banca, generată uzual în mod automat de către un instrument 
(puteţi scrie și manual propriul dumneavoastră s/z/). Cu ajutorul acestei clase se 
facilitează împachetarea și despachetarea datelor aplicaţiei în/din mesaje SOAP 
RPC. 

Liniile de mai jos semnifică o cerere SOAP RPC de la un client către un 
serviciu Web: 

<?xml version="1.0" encoding="UTF-8"?> 

<env: Envelope 

xmlns:env-"http://www.w3.0rg/2002/06/soap-envelope"» 


<env:Body> 
<b:deschideCont env:encodingStyle= 
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"http: //www.w3.org/2002/06/soap-encoding" 
xmlns:b="http://banca.ex.ro/cont" 
xmlns:xs-"http://www.w3.org/2001/XMLSchema" 
xmlns:xsi- 

"http://www.w3.org/2001/XMLSchema-instance"» 
<b:tip xsi:type="xs:string">Firma</b:tip> 
<b:denumire xsi:type="xs:string"> 

Axiologic Research S.R.L. 
</b:denumire> 
<b:sitWeb xsi:type="xs:string"> 

http://www.axiologic.ro 
</b:sitWeb> 

</b:deschideCont> 
</env:Body> 
</env:Envelope> 


După cum se poate remarca, nu este nimic surprinzător într-un mesaj SOAP 
RPC. Respectând specificaţiile, conţinutul este inclus într-un element Body. 
Facem observaţia că în exemplul nostru nu avem blocuri antet, care nu ne sunt 
utile în acest caz, dar SOAP RPC nu exclude astfel de elemente. 

Revenind la exemplu, vedem că numele elementului deschideCont e identic cu 
numele metodei care va fi apelată de serviciul Web. Conţinutul marcatorului 
b:deschideCont va corespunde parametrilor metodei desebideCont(...) prezentată in 
figura de mai sus. Suplimentar, se va mai adăuga atributul xs7:fpe necesar 
destinatarilor mesajului pentru a converti conţinutul fiecărui parametru conform 
tipurilor de date corespunzătoare limbajului de programare ce implementează 
serviciul Web în cauză. 

Răspunsul la cerere respectă un set mai complex de reguli și convenții: 


<?xml version="1.0" encoding="UTF-8"?> 
<env: Envelope 
xmins:env="http://www.w3.org/2002/06/soap-envelope"> 
<env:Body> 
<b:deschideContRespons 
env:encodingStyle= 
"http://www.w3.org/2002/06/soap-encoding" 
xmlns:rpc-"http://www.w3.org/2002/06/soap-rpc" 
xmlns:b="http://banca.ex.ro/cont" 
xmlns:xs-"http://www.w3.org/2001/XMLSchema" 
xmlns:xsi- 
"http://www.w3.org/2001/XMLSchema-instance"» 
<rpc:result>b:nrCont</rpc:result> 
<b:nrCont xsi:type="xsd:int"> 
56291527 
</b:nrCont> 
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</b:deschideContResponse> 
«/env:Body» 
</env:Envelope> 


Sesizăm două aspecte legate de acest răspuns care trebuie discutate. 

În primul rând, numele elementului de răspuns este același cu cel din mesajul 
de cerere, numai că i s-a atașat sufixul Response (în momentul de față, toate 
instrumentele folosesc această convenţie). 

Al doilea aspect constă în faptul că răspunsul este capabil să se muleze pe 
semantica apelului de procedură pentru multe dintre limbajele de programare 
actuale. Acest aspect se datorează suportului pentru parametri de tip i, out, in/out. 
Un parametru de 77 este un parametru de intrare pentru procedura apelată. Un 
parametru oz/ este parametrul care va contine date la terminarea apelului de 
procedură. Un parametru de tip żn/out are caracteristicile ambilor parametri ¿n si 
out. Diferenţa constă în faptul cá un parametru de tip o/zeste similar cu o valoare 
de retur, dar datele conţinute de el pot fi ignorate de către apelantul procedurii. 

Datorită importanţei pe care o valoare de retur o are în numeroase limbaje 
de programare, ea este separată de parametrii 77/ou/, astfel încât în mesajul 
nostru se folosește elementul rpe:resu/t pentru identificarea elementului ce include 
răspunsul dorit. În cazul acesta e vorba de b:nrCont, elementul care contine 
valoarea de retur. Alte elemente care nu sunt referentiate sunt tratate ca simpli 
parametri 77/04. 

Comportamentul este diferit de versiunile anterioare de SOAP, unde valoarea 
de retur trebuia să fie primul element-copil al răspunsului. 

Specificatia SOAP 1.2 a fost modificată astfel încât să se rezolve eventuale 
probleme care puteau apărea (de exemplu, ce se întâmplă în cazul în care nu se 
întoarce nici o valoare de răspuns). 

Este posibil ca și în comunicarea SOAP RPC să apară probleme (excepţii). 
Pentru detectarea și eventual rezolvarea lor, se recurge la avantajul mecanismului 
furnizat de Fault. În plus, au fost adăugate si alte coduri de eroare, al căror spaţiu 
de nume este specificat de adresa hitp://www.w3.org/2002/06/soap-rpc (a se vedea 
tabelul de mai jos). 


Codificarea SOAP privitoare la 
semnalarea erorii 


O eroare apărută la receptor (de exem- 
plu: out of memory) 


Trebuie generată o eroare cu valoarea 
env: Receiver 


Receptorul nu intelege codificarea (cazul 
in care emitátorul foloseste altá codificare 
decát receptorul) 


Trebuie generată o eroare in care Valve are 
valoarea env:DataEncodingUnknown 
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Codificarea SOAP privitoare la 
semnalarea erorii 


Serviciul cate a fost invocat nu contine — | Trebuie generată o eroare in care elementul 
nici o metodă care să se potrivească Code contine elementul Value cu valoarea 
cererii RPC env:Sender, iat elementul SubCode va avea 
Value setat pe mpc:ProcedureNotPresent 


Receptorul nu poate procesa argumentele | O eroare în care elementul Code conţine 
trimise (număr incorect de parametri ori | Value având valoarea env:Sender şi elementul 
nu se potrivesc tipurile de date) SubCode include Value cu rpc:BadArguments 


În exemplul de mai jos avem un caz în care a apărut o eroare SOAP RPC. 
Această situaţie este rezultatul unei cereri construite incorect (nu s-a transmis un 
parametru). Serviciul Web trimite un mesaj de răspuns în care se poate depista 
cauza apariției erorii. Se observă că ne regăsim în ultimul caz expus în tabelul de 
mai sus, în care mesajul de răspuns specifică faptul că a apărut o eroare generată 


de emiţător (<env:Value>env:Sender </env:Value>) și care s-a datorat 
trimiterii unui număr nepotrivit de parametri («env:Value»rpc:BadArguments 
</env:Value>). 


<env:Envelope 
xmlns:env="http://www.w3.org/2002/06/soap-envelope" 
xmins:rpc="http://www.w3.org/2002/06/soap-rpc"> 
<env:Body> 
<env:Fault> 
<env:Code> 
<env:Value>env: Sender</env:Value> 
<env:Subcode> 
<env:Value>rpc:BadArguments</env:Value> 
</env:Subcode> 
</env:Code> 
<env:Reason xml:lang="ro"> 
Lipseşte parametrul &quot;tipéquot;. 
</env:Reason> 
</env:Fault> 
</env:Body> 
</env:Envelope> 


Remarcăm, de asemenea, că în mesaj este utilizat si elementul Reason ce 
include explicații în limbaj natural despre eroarea apărută. 
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8. Versiuni SOAP 


O observaţie interesantă despre SOAP este aceea că elementul Envelope nu 

expune o versiune explicită a protocolului, așa cum fac alte protocoale — un 

exemplu este HTTP (eg, HTTP /1.0 versus HTTP/1.1), iar un altul este WDDX 

(<wddxPacket version="1.0">...</wddxPacket>). 

Proiectantii protocolului SOAP au ales cu bună știință aceasta variantă, 
deoarece s-a observat că suportul oferit de numărul versiunii este destul de fragil. 

Astfel, s-a apelat la utilizarea spaţiilor de nume XML: versiunea protocolului 
este indicată de URI-ul spaţiului de nume corespunzător elementului Envelope. 

Motoarele de căutare/regăsire a serviciilor Web vor cunoaște cum să trateze 
diferite mesaje SOAP cu care ar putea intra în contact conform următoarelor 
reguli: 

e dacă mesajul are o versiune similară cu aceea utilizată de aplicaţie, atunci 
mesajul se va putea procesa; 

* daca mesajul are o versiune mai veche decât orice versiune pe care aplicația 
ştie să o proceseze, atunci pot avea loc două acţiuni: se generează o eroare de 
tipul Version Mismatch şi/sau se trimit clientului informaţii legate de versiunile 
pe care le poate accepta; 

* daca mesajul are o versiune mai nouă decât toate versiunile pe care programul 
în cauză ştie să le prelucreze, atunci se poate alege procesarea mesajului (ceea 
ce nu este întotdeauna o soluţie bună) sau se poate încerca să se trimită 
clientului informaţii privitoare la versiunile pe care le suportă. 


Pe ansamblu, mecanismul versiunilor bazate pe URI-uri oferă o mare flexi- 
bilitate și adaugă o mai mare putere de conciliere între aplicaţii în cazul apariţiei 
mesajelor cu versiuni diferite. 


9. Intermediarii SOAP 


SOAP se caracterizează prin extensibilitate. Apare o extensibilitate pe verticală 
care este conferită de anteturile SOAP. Mai exact, extensibilitatea verticală se 
referă la capacitatea de a introduce noi informaţii în cadrul mesajelor SOAP. 

Există şi o extensibilitate orizontală care se referă la posibilitatea ca diferite 
parti dintr-un mesaj să poată fi procesate de noduri diferite. Această extensibilitate 
orizontală este furnizată de către intermediarii SOAP. 
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Necesitatea existentei intermediarilor 


Intermediarii SOAP sunt aplicaţii care pot procesa parti ale unui mesaj SOAP pe 
drumul pe care acesta îl parcurge de la emițător la destinaţia lui finală. Inter- 
mediarii pot accepta si pot retrimite mesajele SOAP. Există trei motive principale 
care fac necesară prezenţa intermediarilor SOAP: traversarea de domenii de 
încredere (crossing trust domains), asigurarea scalabilitatii si furnizarea unor servicii 
suplimentare de-a lungul căii (rutei) de transport al mesajelor. 

Modul de traversare a mesajului SOAP prin domenii sigure este de fapt o 
problemă care se regăsește în cadrul sistemelor distribuite. Să considerăm relaţia 
dintre o organizaţie şi Internet. În cadrul organizaţiei, calculatoarele formând o 
rețea locală constituie un domeniu sigur, însă Internetul este văzut ca un 
domeniu nesigur. Între aceste domenii există ziduri de protecţie (freall-uri) si 
porți (ga/eway-uri) având rolul de a permite sau nu accesul în „domeniul sigur” al 
Organizației. 

Un alt motiv al prezenţei intermediarilor se datorează necesității de asigurare 
a scalabilitátii sistemelor distribuite. O imagine simplificată a sistemelor distribuite 
e formată din două tipuri de noduri (gazde): unele care formulează cereri 
(clienţii) și altele care furnizează răspunsul la aceste cereri (serverele). Folosind 
acest model, se poate crea un sistem distribuit scalabil, cu oricâte servere la un 
moment dat. Pe acest principiu funcționează si spaţiul Web. 

Să luăm exemplul unui mesaj de e-mail. Avem două companii A si B. 
Corporaţia A trimite un mesaj de e-mail la B, însă serverul de e-mail al acesteia 
este supraincárcat. În aceste condiţii, folosind prioritatea mesajelor si comparând 
cam cât este de încărcat serverul, mesajul poate să treacă printr-o serie de noduri 
intermediare înainte de a ajunge la compania B. Eventual, mesajul va fi stocat 
temporar pe una dintre mașinile intermediare. 

Este clar că într-un astfel de sistem se cere o dirijare a mesajelor care să nu 
se bazeze doar pe parametrii mesajului (emițătorul, receptorul, prioritatea), ci 
trebuie să depindă si de aspecte ca disponibilitatea si încărcarea nodurilor, 
congestia datelor etc. Nodurile intermediare sunt cele care ascund fata de 
emițător si receptor toate aceste entități prin care „navighează” un mesaj. 

Un ultim argument în favoarea existenţei nodurilor intermediare se referă la 
capacitatea acestora de a furniza servicii suplimentare. Unele dintre aceste 
servicii pot fi foarte importante pentru aplicația finală. Să analizăm câteva 
exemple: 


— schimbul de mesaje într-un mediu nesigur (eg., Internet). Pentru a fi siguri cá 
mesajul nu va fi alterat, mai întâi putem trimite mesajul unui intermediar 
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care-l criptează. La recepţie, un alt nod intermediar verifică semnătura digitală 
ataşată si dacă totul este in regulă va decripta mesajul; 

asocierea unor facilități legate de drumul pe care un mesaj îl va parcurge. 
Folosind aceste facilități, mesajul va fi dirijat să treacă exact prin anumiţi 
intermediari, pentru a ajunge la destinaţie în timpul și forma potrivită. Astfel 
de informaţii sunt indispensabile pentru realizarea unor activităţi precum 
asigurarea calității serviciilor (QoS — Quality of Service), identificarea congestiilor 
de date etc. 


Tipuri de intermediari 


SOAP oferă soluţii flexibile la trei din cele mai importante probleme legate de 


nodurile intermediare, răspunzând la următoarele întrebări: 


Cum se pot transmite intermediarilor informaţiile necesare? 

Cum se poate identifica entitatea care procesează datele si ce anume pro- 
ceseazá? 

Ce se întâmplă cu informaţia prelucrată de intermediari? 


Existá douá tipuri de intermediari: 


cate doar retransmit mesajul primit (forwarding intermediaries); 
care modifica si apoi retransmit mesajul (active intermediaries). 


Intermediarii din prima categorie pot realiza următoarele operaţii: 


sterg toate blocurile antet procesate; 

elimina toate blocurile antet care nu mai pot fi retrimise si care au fost 
ignorate atunci cand un nod-tinta a procesat mesajul; 

păstrează toate blocurile antet care pot fi retransmise si care nu au fost 
procesate de nodurile-tinta. 


Intermediarii activi indeplinesc diferite actiuni care pot modifica traseul 


mesajului SOAP (uneori in moduri care nu sunt descrise in blocurile antet ale 


mesajului). Ca exemple de astfel de acţiuni putem menţiona apelul unor servicii 


de 


securitate, invocarea unor servicii care manipulează conţinutul mesajului etc. 


Acţiunile pe care un astfel de intermediar le efectuează trebuie să poată fi 


detectate de nodurile care vor primi mesajul. 


Facem observaţia că informaţia destinată nodurilor intermediare (care se 


găseşte în antet) nu are în general nici o legătură cu informaţia conținută în 


corpul mesajului. 


PROTOCOLUL SOAP 133 


10. O privire asupra SOAP 1.1. O comparatie cu SOAP 1.2 


În acest moment, o multitudine de servicii Web încă folosesc SOAP versiunea 
1.1. Vom discuta în continuare ce diferenţe și asemănări există între cele două 
versiuni. 

SOAP 1.1 se bazează pe XML 1.0 (documente XML text), iar SOAP 1.2 se 
fundamentează pe XML Infoset, o viziune mai abstractă, arborescentă, a tipurilor 
de construcții XML. De asemenea, reprezentările interne bazate pe XML Infoset 
pot conduce la optimizări în ceea ce privește performanţa. 

De asemenea, în SOAP 1.2 au fost schimbate spaţiile de nume XML pentru 
Envelope şi pentru schema de codificare. SOAP 1.2 nu permite existenţa a nici 
unui element după partea de corp a mesajului, pe când definiția schemei pentru 
SOAP 1.1 permitea o astfel de posibilitate — vezi tabelul de mai jos. 


Envelope> Envelope> 
p p 
«Header» Header» 


Zero sau mai multe blocuri Zero sau mai multe blocuri 
antet antet 


«/Header» </Header> 

<Body> <Body> 

Corpul mesajului Corpul mesajului 
</Body> </Body> 

Alte elemente </Envelope> 


</Envelope> 


Organizaţia de standardizare a inter-operabilitatii serviciilor Web — WS-I (Web 
Services Interoperability) — a dezaprobat existenta vreunui element suplimentar dupa 
Body, motivul fiind problemele de incompatibilitate ce ar putea surveni. 

În SOAP 1.2 se defineşte un element antet Misunderstood, în interiorul căruia 
se găsesc informaţii suplimentare despre erorile care au apărut. 

În exemplul următor, receptorul raportează că nu poate înţelege două anteturi 
obligatorii — o:oranges şi p:peaches. 

<e:Envelope> 

<e:Header> 

«f:Misunderstood qname-"o:oranges" /> 
«f:Misunderstood qname-"p:peaches" /» 
</e:Header> 

<e:Body> 

<e:Fault> 
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<e:Code> 
<e:Value>e:MustUnderstand</e:Value> 
</e:Code> 
</e:Fault> 
</e:Body> 
</e:Envelope> 


În SOAP 1.1 se întoarce codul de eroare, dar nici un alt detaliu. De asemenea, 
în SOAP 1.2 atributul wustUnderstand ia valorile logice true sau false, in timp ce în 
SOAP 1.1 valorile permise erau 0 sau 1. 

Versiunea 1.2 a înlocuit atributul actor cu atributul ro/e, în esenţă semantica lor 
fiind asemănătoare. 

În SOAP 1.2, actorului Next din SOAP 1.1 i s-au atașat încă două opţiuni: 


* None — pentru blocurile antet care nu vor fi niciodată procesate in mod direct; 
e Ultimate Receiver — pentru blocurile antet care vor fi procesate de nodul 
destinatar final. 


Noua manieră de semnalare a erorilor în SOAP 1.2 


În ceea ce priveşte semnalarea erorilor, specificatia SOAP 1.2 definește noul cod 
de eroare DataEncodingUnknown, care trebuie generat atunci când un mesaj primit 
folosește o valoare nerecunoscută, corespunzătoare atributului encodingStyle. Codul 
de eroare C/ent din SOAP 1.1 este redenumit Sender în SOAP 1.2, iar codul de 
eroare Server din SOAP 1.1 se regăsește sub numele Receiver în noua versiune. 
Sunt, de asemenea, adăugate noi coduri de eroare pentru RPC (a se revedea 
subcapitolul 7). 

SOAP 1.2 aduce o manieră diferită de structurare a elementelor privitoare la 
erori — vezi tabelul alăturat. 


Fault Fault 
faultcode Code 
Subcode 
Value 


faultstring Reason 


faultactor Node 
Role 
detail Detail 


Dacă SOAP 1.1 permite o extensie a codurilor de eroare folosind notația cu 
» (dot notation), versiunea 1.2 înlocuiește această notație cu o reprezentare XML. 
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<e:Fault> 
<faultcode> 
e:Server.Memory 
«/faultcode» 
<faultstring> 
Out of memory. 


<e:Fault> 
<e:Code> 
<e:Value> 
e:Receiver 
</e:Value> 
<e: Subcode> 


<e:Value> 
Memory 
</e:Value> 
</e:Subcode> 
</e:Code> 
<e:Reason> 


</faultstring> 


</e:Fault> 


Out of memory. 
</e:Reason> 
</e:Fault> 


Modelul de procesare 


SOAP 1.2 clarifică modelul de procesare din SOAP 1.1. Astfel, un nod SOAP 
trebuie să proceseze un mesaj respectând următoarele reguli, în această ordine: 


determinarea rolului pe care îl are de „jucat”. Modalitatea de procesare 
depinde de valorile atributului rok; 

identificarea antetelor obligatorii corespunzătoare nodului-tinta. Astfel, daca 
antetul este marcat cu atributul mustUnderstand="true" și atributul ro/ are 
o valoare care se potrivește cu nodul-tintá, atunci acesta e obligat să proceseze 
acel bloc antet; 

generarea erorii MustUnderstand, dacă unul sau mai multe anteturi nu sunt 
înţelese; aceasta se întâmplă în cazul în care nodul nu contine software-ul 
potrivit pentru procesarea antetului; 

procesarea antetelor, iar — dacă nodul este destinatarul final —prelucrarea, de 
asemenea, a corpului mesajului. 

dacă există un nod intermediar, acesta va şterge partea din antet care îi era 
destinată si va retrimite mesajul. 


Mecanismul versiunilor 


În SOAP 1.2 s-au adăugat noi semantici pentru a putea lucra cu mesaje SOAP 


de versiuni diferite. 


Un nod SOAP 1.2 care primește un mesaj SOAP 1.1 va răspunde cu un 


mesaj SOAP 1.1 care conţine eroarea SOAP 1.1 Version Mismatch. 
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Un nod SOAP 1.2 care primeste un mesaj SOAP de o versiune oarecare 
(inclusiv mesaje din versiunile superioare) va răspunde cu un mesaj (tot de tip 
SOAP 1.2) continand eroarea SOAP 1.2 Version Mismatch si un antet Upgrade cu 
lista versiunilor pachetelor pe care le suporta. 

Un exemplu este următorul: 


<u:Upgrade 
xmins:u="http://www.w3.org/2001/12/soap-envelope"> 
«envelope qname-"nsl:Envelope" xmlns:nsl- 
"http://schemas.xmlsoap.org/soap/envelope/" /» 
«envelope qname-"ns2:Envelope" xmins:ns2- 


"http://www.w3.org/2001/12/soap-envelope" /» 
«/u:Upgrade» 


Maniera de codificare a datelor 


Versiunea 1.2 furnizează o manieră similară de codificare cu SOAP 1.1, însă mult 
simplificată. Vom prezenta în cele ce urmează diferenţele cele mai importante. 
În SOAP 1.2 atributul encodingStyle poate fi folosit ca element-copil doar al 
elementelor Body şi Head si al elementului Detail. În SOAP 1.1, acest atribut este 
permis pentru orice element din mesaj. 
În ceea ce priveşte valorile de tip multi-referenced, pentru SOAP 1.2 acestea pot 
fi codificate diferit fata de versiunea 1.1. 


Vom furniza un exemplu: 


<e:Carti> 
<e:Carte> 
<titlu>Proiectarea 
siturilor Web</titlu> 
<autor 
href="#SabinBuraga" 
/> 
</e:Carte> 
<e:Carte> 
<titlu>Tehnologii 
XML</titlu> 
<autor 
href="#SabinBuraga" 
/> 
</e:Carte> 
</e:Carti> 
<autor id="SabinBuraga"> 


<nume>Sabin Buraga</nume> 
</autor> 


<e:Carti> 
<e:Carte> 
<titlu>Proiectarea 
siturilor Web</titlu> 
<autor 
id="SabinBuraga"> 
<nume> 
Sabin Buraga 
</nume> 
</autor> 
</e:Carte> 
<e:Carte> 
<titlu>Tehnologii 
XML</titlu> 
<autor 
ref="SabinBuraga" 
/> 
</e:Carte> 
</e:Carti> 
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Elementele din schema de codificare SOAP difera intre SOAP 1.1 si SOAP 
1.2, dupa cum se poate remarca din tabelul de mai jos: 


5 SOAP 1.1 SOAP 1.2 


Atribut href ref 
Tip uri-reference IDREF 


Exemplu #SabinBuraga SabinBuraga 
http://www.sit.ro/csb.gif 


In ceea ce priveste tablourile, in SOAP 1.2 nu mai intalnim matricele rare 


(sparce array). Faţă de SOAP 1.1, atributul arrayType a fost înlocuit cu itemType si 
cu atributul arraySize. Să urmărim tabelul: 


<numere enc:arrayType= <numere 
"xs:int[2]"» enc:itemType="xs:int" 
<numar>29</numar> enc:arraySize-"2"» 
<numar>10</numar> <numar>29</numar> 


</numere> <numar>10</numar> 


</numere> 


Specificatia SOAP 1.1 include atributul root care poate fi utilizat pentru a 
marca rădăcina schemei/grafului de codificare. În SOAP 1.2 acest atribut este 
eliminat. 

În SOAP 1.2 omiterea unui accesor este echivalentă cu NIL. Semantica 
accesorului NIL este însă dependentă de aplicaţie. 


Mecanismul RPC 


SOAP 1.1 oferă un model de implementare care constă în existenţa unui nod 
destinatar SOAP dat sub forma unui URI, iar în cererea SOAP se regăsește 
logica aplicaţiei. O astfel de abordare implică ascunderea sub „umbrela” unui 
URI a tuturor resurselor care pot fi oferite de un nod, împiedicându-se astfel 
accesarea individuală a fiecărei resurse dorite. 

Să revenim la exemplul nostru cu portocale și să considerăm că firma cu 
situl www.portocale.info oferă servicii precum: aflarea preţului unui anumit sor- 
timent de portocale, obţinerea datelor privind ofertele promoţionale etc. Dacă 
aceste servicii ar fi plasate sub același URI, ele ar fi efectiv ascunse. O astfel 
de abordare reduce Web-ul la un nivel de transport și neagă caracterul robust 
si scalabil al arhitecturii spațiului WWW (în stilul REST amintit în primul 
capitol). 
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SOAP 1.2 recomandă ca resursele să fie identificate de URI-uri separate. 
Acest aspect permite ca resursele SOAP să poată fi accesate nu numai via HTTP 
POST, ci si prin metoda GET. 

SOAP 1.2 acceptă utilizarea fie a tablourilor, fie a structurilor pentru repre- 
zentarea răspunsurilor sau apelurilor RPC, în contrast cu SOAP 1.1, care permitea 
doar folosirea de structuri. Serializarea bazată pe tablouri este utilă în condițiile 
în care numărul de argumente nu este cunoscut dinainte. 

În următorul exemplu avem apelul unei funcţii de adunare de numere, care 
are un număr variabil de argumente: 


<e:Envelope xmlns:e='...'> 
<e:Body> 
<a:adunaNumere xmlns:a='...' e:encodingStyle='...'> 
<n>29</n> 
<n>15</n> 
<n>33</n> 
</a:adunaNumere> 
</e:Body> 
</e:Envelope> 


De asemenea, în SOAP 1.2 corpul mesajelor SOAP care folosesc codificarea 
SOAP pentru RPC trebuie să conţină un singur element-copil, acesta repre- 
zentând apelul sau răspunsul RPC sub formă de structură sau tablou. 

În următoarele linii, elementul Body este valid în raport cu codificarea SOAP, 
dar nu este valid când este folosit în conjunctie cu convențiile RPC. 


<e:Envelope xmlns:e='...'> 
<e:Body> 
<a:adunaNumere xmlns:a='...' e:encodingStyle='...'> 


<n ref='unNumar' /> 
<n ref-'unNumar' /> 
</a:adunaNumere> 
<n id-'unNumar'»33«/n» 
</e:Body> 
</e:Envelope> 


În cele de mai jos, elementul Body va fi valid atât in raport cu codificarea 
SOAP, cât si atunci când apare în legătură cu conventiile RPC. 


<e:Envelope xmlns:e='...'> 
<e:Body> 
<a:adunaNumere xmlns:a='...' e:encodingStyle='...'> 


«n id-'unNumar'»33«/n» 
«n ref-'unNumar' /» 


PROTOCOLUL SOAP 139 


</a:adunaNumere> 
</e:Body> 
</e:Envelope> 


Versiunea 1.2 introduce si noi coduri de eroare specifice RPC: ProcedureNotPresent 
și BadArguments. 

Referitor la valorile RPC întoarse, SOAP 1.2 adaugă noi convenţii pentru 
reprezentarea acestora: 


<e:Body> <e:Body> 
<b: deschideContResponse> 
<b:nrCont> «rpc:result» 


<b:deschideContResponse> 


56291527 
</b:nrCont> 
</b:deschideContResponse> 


b:nrCont 


«/rpc:result» 
«b:nrCont» 


«/e:Body» 56291527 

</b:nrCont> 
</b:deschideContResponse> 
</e:Body> 


Legătura cu HTTP 


Vom prezenta în rândurile următoare diferențele între legătura HTTP cu SOAP 
1.1, respectiv cu SOAP 1.2. Tipul #xt/xm/ folosit in SOAP 1.1 a fost înlocuit in 
versiunea 1.2 cu application/ soap+ xml. 

În SOAP 1.1 s-a pus problema folosirii doar a metodei POST pentru 
transportul mesajelor SOAP via HTTP. Versiunea 1.2 oferă suport si pentru 
utilizarea metodei GET. Metoda GET asigură că acțiunile de cerere sau de 
răspuns realizate de un nod SOAP sunt sigure si idempotente, fără efecte 
secundare (side effects). 

SOAP 1.1 menționa că în antetul HTTP apare atributul SOAPAction, care 
poate fi folosit pentru a preciza scopul mesajului pe baza unui URI. Pentru 
SOAP 1.2, conținutul acestui atribut poate fi specificat cu ajutorul parametrului 
optional action, ce poate fi atașat tipului MIME application/soapt+xml. Valoarea 
parametrului action va fi desemnată printr-un URI absolut, nu neapărat rezolvabil, 
putând fi folosită de diverse entități (eg., firewall-uri) pentru filtrare. 

Suplimentar, SOAP 1.2 oferă o descriere mai detaliată a codurilor de stare 
HTTP, de exemplu 2xx sau 4xx, pentru raportarea posibilelor situații ce pot 
surveni. 
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Securitatea in SOAP 


SOAP 1.2 a adus clarificări versiunii 1.1 din multe puncte de vedere, însă la nivel 
de securitate oferă destul de puţine noutăți. 

Din acest motiv programatorii trebuie să urmeze anumiţi pași aditionali si să 
utilizeze diverse tehnici de criptare pentru protejarea mesajelor SOAP — a se 
parcurge și cele prezentate în capitolul 7. 

De asemenea, dezvoltatorii de instrumente SOAP trebuie să prevadă situațiile 
în care nodurile SOAP pot primi mesaje cu diferite date eronate. Este recomandat 
ca nodurile SOAP să aibă capacitatea să evalueze care este nivelul de încredere 
în emițătorul unui mesaj si în conţinutul aferent. 
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Capitolul 5 


Descoperirea serviciilor 


„Raționamentul meu nu trebuie interpretat 
ca afirmaţie, ci drept întrebare.” 


(Niels Bohr) 


Descoperirea serviciilor este una dintre cele mai importante probleme dez- 
batute pe larg in cadrul comunitatii serviciilor Web. Aceasta, de fapt, poate fi 
formulată cu ajutorul unei întrebări simple: cum poate afla un client despre 
existenţa și modul de utilizare a unui serviciu? 

Procesul de descoperire a serviciilor Web poate fi unul centralizat sau 
distribuit. Există mai multe abordări de soluționare a acestei probleme, care 
constituie subiectul capitolului de fata. 


1. Descoperirea serviciilor Web prin UDDI 


Cele mai multe aplicații destinate comerțului electronic si care recurg la servicii 
Web urmează căi divergente pentru conectarea cumpărătorilor, furnizorilor de 
produse, pieţelor si ofertantilor de servicii. Fără largi investiţii în infrastructura 
tehnologică, companiile de toate mărimile și tipurile pot tranzactiona afaceri 
bazate pe Internet doar cu parteneri globali deja cunoscuţi și care furnizează 
aplicaţii și servicii Web compatibile. 

Specificaţiile UDDI (Universal Description, Discovery, and Integration) au ca scop 
definirea unui set de servicii care să permită descrierea și descoperirea: 


— afacerilor, organizaţiilor si a altor furnizori de servicii Web; 
— serviciilor Web pe care diverse entităţi le pun la dispoziţie; 
— interfetelor cu ajutorul cărora pot fi accesate aceste servicii. 


UDDI reprezintă nivelul superior în stiva formată din tehnologii ca TCP/IP, 
HTTP, XML, XML Schema si SOAP, cu care cititorul este deja familiarizat. 
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1.1. Scurt istoric 


Atunci când a apărut UDDI, cea mai mare atenţie s-a fixat asupra UBR (UDDI 
Business Registry) — o implementare publică a standardului UDDI, care este de 
fapt un catalog principal folosit pentru publicarea serviciilor de tip e-commerce. 
Deşi UBR rămâne un aspect important în ceea ce privește UDDI, el reprezintă 
doar o componentă a acestuia. 

Tabelul următor sintetizează nivelurile specificațiilor UDDI (standardele 
disponibile de-a lungul anilor): 


Versiunea Anul 


UDDI lansării Obiectiv 


Crearea cadrului pentru cataloage (registri) destinate ser- 
viciilor de tip e-business. 


Alinierea specificațiilor la standardele Web existente și 
furnizarea unei taxonomii flexibile a serviciilor. 


O principală caracteristică este cea de adăugare a supor- 
tului pentru securitate. 


Actualmente este în vigoare UDDI 3.0, bazat pe mai vechiul standard UDDI 
2.0 propus de OASIS (Organization of the Advancement of Structured Information 
Standards). 

UDDI poate fi considerat drept un meta-serviciu folosit pentru localizarea 
serviciilor Web, permițând in același timp interogări „robuste”, în raport cu 
cantitatea imensă de meta-date privitoare la serviciile Web oferite de diverși 
implementatori. 


1.2. Concepte de bază ale UDDI 


Modelul de date UDDI 


În figura 1 se pot remarca principalele entităţi stocate in registrii UDDI, 
suplimentar fiind ilustrate si relatiile dintre ele. 

Tipurile de date folosite (care constituie nucleul modelului UDDI) sunt 
definite cu ajutorul unor scheme XML. A fost ales formatul XML, deoarece este 
independent de platformă si permite exprimarea într-un mod natural a relaţiilor 
ierarhice. 

Schemele XML utilizate de UDDI specifică diverse tipuri de date funda- 
mentale necesare utilizatorilor și aplicaţiilor în vederea folosirii unui serviciu 


Web. 
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businessEntity 


bindingTemplate j 


subscription 


Figura 1. Tipurile de date UDDI şi relațiile stabilite între acestea 


Tipurile de informații de bază sunt următoarele: 


e businessService — descrie o colecție de servicii Web înrudite, oferite de o 
organizație desemnată de businessEntity; 

e businessEntity — semnifică informația privitoare la organizația care publică un 
serviciu; 

e bindingTemplate — specifica detalii tehnice despre serviciu, incluzând o referință 
la interfața de programare (API-ul) serviciului; 

* Model — descrie un model tehnic (zechnical model) reprezentând un concept 
reutilizabil, cum ar fi tipul unui serviciu Web, un protocol folosit de serviciile 
Web, diverse alte atribute sau meta-date (¢.g., semnături digitale, relații cu alte 
servicii etc.). 
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businessEntity 

- date despre entitățile 

care publică informații 

despre un serviciu tModel mE 
- descrieri ale 
specificatiilor 
serviciului sau datelor 


businessService 
- informatii descriptive 
despre o suita specifica 


de servicii tehnice 


contine 


face referinta spre 


bindingTemplate 

- informatii tehnice 
despre interfața şi 
implem. unui serviciu 


conţine 


Figura 2. Tipurile de informații de bază UDDI 


O structură de tip businessEntity contine una sau mai multe structuri distincte 
de tip businessService. Similar, o structură de tip businessService poate include una 
sau mai multe structuri bindingT emplate. 

În versiunile recente există încă două tipuri de date care facilitează afilierea 
registrilor: 

e publisherAssertion — semnifică relațiile dintre entităţile stocate într-un registru; 
e subscription — menţine anumite cereri pentru a se detecta schimbările care pot 
avea loc în ceea ce priveşte un set de entități. 


Toate aceste tipuri de date sunt stocate persistent de regiștrii UDDI. Pentru 
un anumit catalog UDDI, structurii de date fundamentale i se asociază un 
identificator unic, în acord cu o anumită schemă standard. Acest identificator se 
numește cheie (UDDI key). 

Mai remarcăm și faptul cá o anumită structură businessEntity (identificată de o 
cheie unică) va conţine întotdeauna o anumită instanţă a unei structuri de tip 
businessService (specificată de propria sa cheie). 

De oricâte ori este necesar, prin intermediul acestor chei pot fi folosite 


referinţe la o anumită entitate. 
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Informaţiile de tip businessEntity 


Fiecare intrare de tip businessEntity stochează date descriptive privitoare la o 
afacere sau organizaţie si, prin intermediul entităților businessService pe care le 
conţine, pune la dispoziţie informaţii despre serviciile oferite. 

O entitate businessService descrie un serviciu, dintr-un anumit punct de vedere. 
Similar, fiecare bindingTemplate inclus într-o structură businessService furnizează o 
descriere tehnică a serviciului Web care aparține serviciului logic declarat de 
businessService. 

Structura businessEntity contine următoarele elemente: 


— uddi:discoveryURLs, care reprezintă o listă de URL-uri care indica spre docu- 
mente conţinând mecanisme de descoperire; avem mai jos un exemplu: 


<discoveryURLs> 
<discoveryURL useType="businessEntity"> 
http://ws.portocale.info?businessKey 
-uddi:portocale.info:registry:Sales:74 
</discoveryURL> 
</discoveryURLs> 


— uddi:name, care este un element obligatoriu, semnificând numele procesului 
global de afacere oferit (de exemplu, managementul ordinelor de plata); 
— uddi:description, ce oferă o descriere, fiind un element optional; 
— uddi:contacts, ce include informaţii de contact privitoare la entitatea care a 
publicat serviciul; un exemplu este următorul: 
<contacts> 
<contact useType="Sales"> 
<personName>Blue Ory</personName> 
<email>blue.ory@portocale.info</email> 
</contact> 
</contacts> 


— uddi:businessServices, care reprezintă o lista de servicii furnizate de businessEntity; 

— uddiidentifierBag — pe lângă businessKey, care identifică în mod unic o structură 
businessEntity într-un registru, acest element optional permite ca structurile 
businessEntity să poată fi regăsite în acord cu un sistem de identificare public; 

— uddi:categoryBag — contine o lista de categorii de afaceri — de exemplu, dupa 
industrie, după regiunea geografică etc. —, fiecare descriind un anumit aspect 
conform unei taxonomii alese (&g, schema de clasificare NAICS — North 
American Industry Classification System); 

— dsig:Signature, reprezentând o semnătură digitală XML atașată unei entități 
businessEntity. 
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Notam faptul că elementele name, description şi contacts oferă informaţii textuale 
privitoare businessEntity, eventual in mai multe limbi. 

Orice instanță a elementului businessEntity este identificată in mod unic de 
atributul businessKey. Atunci când o structură de tip businessEntity este publicată 
într-un registru UDDI, atributul businessKey trebuie omis în cazul în care cel care 
publică informaţiile doreşte ca registrul să genereze automat o cheie. Atunci 
când o entitate de tip businessEntity este obţinută dintr-un registru UDDI, 
atributul businessKey trebuie să existe obligatoriu. 


Informațiile de tip businessService 


Elementul businessService este o structură reprezentând un serviciu specificat logic 

si conţine informaţii descriptive în termeni de afaceri. Informaţii tehnice despre 

businessService se găsesc în structurile de tip bindingTemplates (vezi infra). 
Structura businessService încapsulează următoarele elemente: 


— uddi:name, care semnifică numele serviciului din cadrul procesului de afacere 
oferit (e.g., receptionarea unui ordin de plată); 

— uddi-description, cate specifică o descriere a serviciului; 

— uddi:bindingTemplates — este o listă de descrieri tehnice a serviciilor Web 
furnizate de businessService; 

— uddi:categoryBag, ce contine o lista de clasificări ale afacerilor, fiecare descriind 
un aspect al elementului businessService; 

— dsig:Signature reprezentând o semnătură digitală asociată entității businessService. 


Elementului businessService îi sunt ataşate şi atributele: 


— serviceKey, ce identifică în mod unic o entitate businessService; 
— businessKey reprezentând o cheie referitoare la o intrare businessEntity. 


Când o informatie de tip businessKey este inclusă într-un registru UDDI, 
atributul serviceKey poate fi omis dacă organizaţia care o publică doreşte ca 
registrul să genereze o cheie. Atunci cand businessEntity este obţinut de la un 
registru, atributul serviceKey trebuie să fie prezent. 

Atributul businessKey identifică în mod unic o informatie businessEntity care 
furnizează o structura businessService. Fiecare entitate businessService este inclusă 
într-o singură structură businessEntity. 

Un exemplu de intrare de tip businessService este următorul (cheile sunt furnizate 
sub formă de identificatori unici universali de tip UUID; pentru UDDI versiunea 
3, acești identificatori nu trebuie neapărat să fie numerici): 


DESCOPERIREA SERVICIILOR 149 


<businessEntity ...> 


<businessServices> 
<businessService 
businessKey-"uuid:..." serviceKey-"uuid:..."» 
<name>Preia un ordin de plată</name> 
«description xml:lang="ro"> 
Serviciu pentru receptionarea 
ordinelor de platá. 
«/description» 
<bindingTemplates> 


</bindingTemplates> 
<categoryBag> 


</categoryBag> 
</businessService> 
</businessServices> 


</businessEntity> 


Informaţiile de tip bindingTemplate 


Entitátile LindingTemplate furnizează descrierile tehnice pentru serviciile Web. Un 
element bindingT emplate corespunde unei instante a serviciului oferit la o anumită 
adresă, in general furnizând URI-ul acesteia. De asemenea, acest element face 
referiri la datele de tip ‘Mode/ (pe care le vom descrie mai jos), precum si la 
parametri și setări specifice aplicației. 

Structura bindingTemplate contine următoarele elemente: 


— uddi:description, care oferă informaţii textuale despre bindingTemplate; 

— uddi:accessPoint, care este un sit de caractere ce permite accesul la serviciul Web 
desctis. În mod obișnuit, este un URI, dar poate fi si o adresă de e-mail sau 
chiar un număr de telefon; 

— uddichostingRedirector, ce reprezintă un element folosit doar pentru păstrarea 
compatibilitatii cu versiunea UDDI 2.0. Functionalitatea sa este acoperită de 
uddi:accessPoint; 

— nddi:tModellnstanceDetails, care semnifică o listă de unul sau mai multe elemente 
tModelInstancelnfo. Colecţia de atribute ZMode/Key existente în elementele ZMode/- 
Instancelnfo formează aşa-numita amprentă tehnică a serviciului Web, care 
poate fi folosită pentru identificarea serviciilor compatibile. 

— uddi:categoryBag, ca mai sus, reprezintă o colecţie de categorii asociate serviciului; 

— dsign:Signature, ce semnifică o semnătură digitală. 
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Similar sunt specificate si atributele bindingKey si serviceKey, având aceleași 
semnificații ca în cazul anterior. 
Un exemplu este următorul: 
<businessService ...> 
<bindingTemplates> 
<bindingTemplate 
serviceKey="uuid:..." bindingKey="uuid:..."> 
<accessPoint URLType="http"> 
http://ws.portocale.info:3333/Sales 
</accessPoint> 
<tModelInstanceDetails> 


</tModelInstanceDetails> 
</bindingTemplate> 
</bindingTemplates> 
</businessService> 


1.3. Structura tModel 


Unul dintre scopurile UDDI este acela de a facilita găsirea cu ușurință a 
serviciilor Web. Un alt obiectiv este cel de a oferi descrieri complete ale acestor 
servicii, astfel încât oamenii și programele să poată interactiona ușor cu servicii 
despre care nu știau mai nimic în prealabil. Aceste scopuri sunt de fapt trăsăturile 
esenţiale ale structurilor *Mode/. Entitatile de bază UDDI sunt tocmai instanţele 
tModel. 

La nivel general, scopul elementelor “Mode/ este de a furniza un sistem de 
referinta abstract. Exista doua motive principale pentru utilizarea structurilor 
tMode/: determinarea compatibilitatii între serviciile Web si folosirea lor drept 
referinte la un spatiu de nume fixat. 


Util/zare 


Din punct de vedere al utilizării, o instanță a unei structuri ¿Model poate fi 
referita de mai multe structuri businessEntity. De asemenea, în diferite apeluri ale 
interfeţei de programare pot apărea referiri la /Mode/. 

Utilizarea cea mai obișnuită a elementelor ‘Mode/ este în reprezentarea 
specificaţiilor tehnice si a conceptelor. De exemplu, un ‘Model poate fi folosit 
pentru a reprezenta o specificaţie care definește un protocol de transport wireless, 
formatul interschimburilor de date si secvenţa de reguli ce trebuie urmate în 
procesul de schimb al mesajelor. 
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O aplicaţie care comunică cu o alta va prefera, desigur, să adere la specificaţii 
(convenţii) prestabilite. În acest caz, proiectantii acestor specificaţii pot stabili o 
identitate tehnică unică într-un registru UDDI, publicând informaţii despre 
acestea în cadrul unui ‘Model. 

În timp ce principalul motiv pentru înregistrarea unui /Mode/ într-un registru 
UDDI este definirea unei identități, specificatia reală sau setul de documente 
care descriu conceptul 7Mode/-ului nu vor face parte din registru, însă vor putea 
fi referite (cu ajutorul structurii overviewDoc). Evident, cei care publică astfel de 
documente, specificând conceptul pe care un ‘Mode/ il reprezintă, trebuie să 
ofere descrieri folosind formate și limbaje bine-cunoscute. 

Din moment ce un {Model a fost publicat, alte organizaţii pot considera cá un 
anumit serviciu Web pe care îl furnizează respectă specificaţiile acestuia și își 
afirmă ,,disponibilitatea” prin simpla incluziune a unei referinţe la acel ZMode/ 
(folosindu-se #Mode/Key din structura bindingTemplate) — un mod similar este cel in 
care cineva poate „cita” un document Web, făcând o referire la acesta printr-o 
legătură hipertext desemnată de un URI. 

Această abordare facilitează găsirea serviciilor Web compatibile cu o anumită 
specificaţie. Odată ce o valoare validă pentru ZMode/Key este cunoscută, este ușor 
de descoperit că o anumită entitate particulară de tip businessEntity are asociat un 
serviciu Web referentiind un /Mode/, În acest mod, un /Mode/Key devine așa-numita 
amprentă tehnică (¢echnical fingerprint), unică pentru o anumită specificaţie. 

Elementele #Mode/ pot fi incluse în cadrul marcatorilor sdentifierBag, categoryBag, 
address şi publisher Assertion care sunt folosiţi pentru specificarea identităţii organi- 
zationale si a diferitelor categorii. Utilizat în acest context, un ZMode/ desemnează 
un sistem de valori folositor pentru identificarea sau clasificarea entităților 
UDDI, având astfel un rol în constituirea unor taxonomii referitoare la serviciile 
Web. 

Pentru a reprezenta faptul că o anumită afacere descrisă de elementul 
businessEntity ate un anumit identificator ID asociat, AeyedReference este plasat 
într-un zdentifierBag. Acest ReyedReference va avea atributul &eyl/z/u cu valoarea 
identificatorului ID dat si referă un ‘Mode/ semnificând „sistemul identificat de 
ID”. Împreună, keyValue şi referinţa la ‘Model specifică o valoare particulară 
într-un anumit sistem de valori. 


Structura unui element de tip tModel 


Un element ZMode/ este compus din următoarele sub-elemente: 


— uddi:name care asociază un nume unic, obligatoriu (in general este un URI); 
— uddi:description, reprezentând o descriere textuală opţională; 
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— uddi:overviewDoc, care face referire la informaţii privitoare la ZModeZ include un 
element overriewURL ce reprezintă adresa la care se găsește documentul 
descriind /Mode/-ul. Atributul zselype al marcatorului overviewURL poate avea 
mai multe valori. Dacă valoarea lui este ,,/ex7", atunci înseamnă cá overview URL 
contine informaţii textuale. O altă valoare des întâlnită pentru wseType este 
wsdlInterfaee, ceea ce semnifică faptul cá overviewURL referă un document 
WSDL care poate fi reutilizat de diferite implementări; 

—  uddiiidentifierBag, ce contine o lista de identificatori logici, cu rol de meta-date; 


— uddi:categoryBag, care furnizează o listă de clasificări descriind anumite aspecte 
ale /Mode/-ului. 


Structura ‘Model are asociate si atributele: 


e tModelKey, care identifică în mod unic un 7Mode/ 
* deleted este un câmp care specifică dacă /Mode/ul a fost şters logic (valorile 
sale pot fi /rue sau false). 


Un exemplu de informaţii conţinute de un ZMode/ este următorul, descriind 
comportamentul unui serviciu Web: 


<tModel tModelKey="uuid:..."> 
<name>Vânzări online de portocale</name> 
<description xml:lang="ro">...</description> 
<overviewDoc> 
http://ws.portocale.info:3333/Sales?WSDL 
</overviewDoc> 


<identifierBag>...</identifierBag> 
<categoryBag>...</categoryBag> 
</tModel> 


1.4. Informaţii privitoare la publicarea serviciului 


Structura publisherAssertion 


Multe afaceri şi organizaţii nu sunt efectiv reprezentate de o singură entitate de 
tip businessEntity. Atunci când o organizaţie este desemnată de mai multe structuri 
businessEntity, s-ar dori ca acestea să fie interconectate prin relaţii vizibile. Aceasta 
se poate realiza cu ajutorul elementului publisherAssertion. 

Pentru a elimina posibilitatea ca o entitate care a publicat un serviciu să 
revendice o relaţie care nu e reciprocă, ambii parteneri trebuie să facă publice 
aceleași „afirmaţii” pentru ca relația lor să devină vizibilă (se asigură astfel 
reciprocitatea). 
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Structurii publisher Assertion ii corespund următoarele elemente: 


e uddi:fromKey — identifică instanţa „sursă” de tip BusinessEntity care stabileşte 
acordul (relaţia); 

e uddi:toKey — specifică instanţa ,,destinatie” de tip BusinessEntity participantă la 
acord; 

° uddi:keyedReference — descrie relaţia dintre cele două părți; 

° dsig:Signature— desemnează o semnătură digitală XML. Atunci când o structură 
Publisher Assertion este semnată, fiecare semnătură digitală trebuie să fie furnizată 
de propriul element dszg:Signature. 


Structura operationalInfo 


La publicarea unui serviciu, în registrul UDDI sunt stocate și o serie de informaţii 
operaţionale, incluzând data și timpul la care structura de date a fost creată sau 
modificată, identificatorul nodului UDDI si identitatea celui care a publicat 
datele. 

Aceste informaţii operaţionale vor fi memorate într-un element operationallnjo, 
pentru structurile de date de tip businessEntity, businessServices, binding l'emplate si 
tModel. 

Sub-elementele care pot fi folosite in cadrul operationallnfo sunt created, modified, 
modifiedlncludingChildren, nodelD, authorizedName. Entitatea UDDI care are asociată 
o structură operationallnfo se identifică prin atributul obligatoriu enzityKey. 


1.5. Taxonomia entităţilor UDDI 


UDDI furnizează o structură semantică a informaţiilor referitoare la serviciile 

Web dintr-un registru. UDDI permite utilizatorilor să definească taxonomii 

multiple. Astfel, utilizatorii nu sunt legaţi de un singur sistem taxonomic, ci pot 

folosi un număr nelimitat de clasificări dorite. 

Specificatiile UDDI includ anumite definiţii privitoare la relaţiile ierarhice 
dintre o instanţă a unei implementări UDDI și alte entități de care aceasta este 
legată. 

Serverele UDDI sunt împărţite în următoarele tipuri: 

* nod (node) — este un server UDDI care suportă minimul de funcționalități 
definite în specificaţie. Poate executa una sau mai multe operaţii asupra 
datelor UDDI la care are acces. Este membrul unui singur registru UDDI; 

e registru/catalog (registry) — este format din unul sau mai multe noduri. Un 
registru executa setul complet de functionalitati definit in specificatiile UDDI. 
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* registri afiliati (affiliated registries) — sunt regiștrii UDDI care implementează 


reguli de partajare a informaţiilor. Acești registri afiliati partajeazá un spațiu 


de nume comun pentru cheile UDDI care identifică în mod unic înregistrările 


de date. 


In versiunea 3.0, una dintre modificările esenţiale este cea privitoare la 


conceptul de registri afiliați. Să urmărim mai jos câteva aspecte referitoare la 
tipurile de registri UDDI: 


SI : Descriere pup a 
registrului aplicatie 


De tip 
enterprise sau 
privat 
(corporate/ 
private) 


De tip afiliat 
(affiliated) 


Un registru intern, al unei intreprinderi, aflat in 
spatele unui firewa// izolat de Internet. Accesul la 
facilitățile administrative si la datele din registri este 
restricționat. Datele nu sunt partajate cu alti registri. 


Un registru dezvoltat în cadrul unui mediu controlat 
si cu acces limitat la clienți autorizați. Funcțiile de 
administrare pot fi realizate si de alt partener de incre- 
dere. Datele pot fi partajate cu alti registri într-o 
manieră controlată. 

Din perspectiva unui utilizator final, un registru 
public este un serviciu obişnuit. Desi funcțiile admi- 
nistrative pot fi securizate, accesul la datele din regis- 
tri este public. Datele pot fi partajate sau transferate 
între diferiți registri, iar conținutul propriu-zis poate fi 
sau nu moderat. 


Catalog UDDI la 
nivel de corpo- 
ratie (Enterprise 

Web Service 
Registry) 


Reţea de par- 
teneri comerciali 
(Trading Partener 
Network) 


Catalog de tip 
UDDI Business 
Registry (UBR) 


Altfel spus, afilierea permite sistemului UDDI să suporte o varietate de 


topologii de reţele sau de infrastructuri. Structura unui registru UDDI permite 


reflectarea realității existente în interacţiunile reale dintre entitățile business. 


Managementul versiunilor multiple ale datelor stocate de regiștrii UDDI 


constituie o reală provocare pentru o astfel de infrastructură distribuită. Spe- 


cificatiile UDDI oferă un cadru care să faciliteze menţinerea și asocierea de chei 


UDDI înregistrărilor din regiștri, dar nu pun în discuţie existenţa vreunui suport 


de definire de scenarii business. Regulile de afaceri si scenariile aferente se lasă în 


responsabilitatea dezvoltatorului software care însă, poate folosi infrastructura 
de bază oferită de UDDI. 


DESCOPERIREA SERVICIILOR 155 


domeniu semi-privat 
wr p 


Lint 
pubtiish 


ajefeyred miourop 


MEE N C S 
PUDLUSI 


Figura 3. Tipurile de registri si interacțiunile între aceştia (RP = registru privat, RPA = 
registru privat afiliat, UBR = UDDI Business Registry) 


In figura de mai sus sunt descrise o serie de moduri de interactiune intre 
registri. Prin mecanisme de tip publicare/abonare (publish/ subscribe) si replicare 
(replication) intre nodurile unui registru, informatiile de pe serverele UDDI pot fi 
in totalitate publice (cazul UBR), semi-private sau total private si izolate (situatia 
unei corporaţii folosind servicii Web interne, la nivel de intranet propriu). 


1.6. Interfete de programare pentru UDDI 
În cadrul specificaţiilor UDDI sunt definite două categorii de interfețe de 


programare principale: Publisher API si Inquire API. 


Publisher API 


Interfata Publisher API permite publicarea si actualizarea de informatii continute 
în regiștrii UDDI. Funcţiile puse la dispoziţie sunt descrise de tabelul următor. 
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Metoda Descriere 


add_publisherAssertions 


Adauga una sau mai multe relatii specificate de 
Publisher Assertion 


delete_binding 


Sterge una/mai multe instante ale elementului 
binding Lemplate din registri 


delete. business 


Şterge una/mai multe înregistrări de afaceri 


delete_publisherAssertions 


Elimină unul/mai multe elemente publisherAssertion 


delete_service 


Şterge unul/mai multe elemente businessService 


delete _tModel 
discard_authToken 


Şterge logic una/mai multe structuri Mode/ 


Informeaza un nod că informaţiile de autentificare 
vor fi înlăturate 


get_assertionS tatus Report 


Raportează starea declaraţiilor care implică orice 
înregistrare de afacere a cărui management este 
realizat de un anumit publisher 


get_authToken 


Obtine un jeton de autentificare 


get_publisherAssertions 


Furnizeaza toate relaţiile de tip publisherAssertion 
realizate de un publisher 


get. registeredlnfo 


Obtine o lista a tuturor structurilor businessEntity si 
tModel 


save binding 


Salveazá/actualizeazá un element binding Template 


save. business 


Salveazá/actualizeazá o structurá businessEntity 


Save_service 


Adaugă /actualizează unul ori mai multe elemente 


business ervice 


save_tModel 


Salvează sau actualizează unul/mai multe elemente de 


tip Model 


Inlocuieste toate declaraţiile de tip publisherAssertion 
ale unui publisher 


set_publisherAssertions 


Inquiry API 


Interfata de programare Inquiry API permite operaţii pentru căutarea si parcurge- 
rea registrilor cu scopul de a obtine informatii despre o anumita afacere sau un 
serviciu dorit. Tabelul de mai jos sintetizează lista functionalitatilor oferite. 


Metoda Descriere 


find. binding Localizeazá o informatie de legare (binding) a unui serviciu la 
un protocol (tip, port etc.) in cadrul unui sau mai multor 
elemente businessService 


find. business 


Localizeazá informatii despre una/mai multe afaceri 


find. relatedBusinesses | Localizeaza informaţii despre înregistrările businessEntity 


asociate unei anumite entitáti de afaceri 


find. service Localizeazá anumite setvicii in cadrul unor entitáti de afaceri 
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Metoda Descriere 


jind_tModel Localizeazá una/mai multe structuri ZMode/ 


get_bindingDetail Obtine informaţii detaliate pentru realizarea de cereri 
privitoare la binding Iegplate 


get_businessDetail — | Obtine informaţii despre businessEntity pentru una sau mai 
multe afaceri/organizatii 


get_businessDetailExt | Purnizeazá informaţii detaliate despre businessEntity 


get_serviceDetail Obtine detalii complete despre un set de entități businessService 


get_tModelDetail Furnizează detalii referitoare la un ZMode/ 


Publisher API şi Inquiry API reprezintă nucleul instrumentelor care realizează 
managementul datelor din cadrul registrilor UDDI. 

De notat faptul că marile companii pun la dispoziţie cataloage de tip UBR ce 
pot fi accesate via API-urile prezentate mai sus. Cateva exemple notabile sunt 
următoarele: 


— accesarea interfeţei de interogare a registrului UBR de la IBM: Aitp:/ / uddi. ibm.com/ 
ubr/ inquiryapi 

— accesarea interfeței de publicare în registrul UBR oferit de IBM: /ips://uddi.ibm.com/ 
ubr/ publishapi 

— accesarea interfetei de interogare a registrului UBR pus la dispozitie de 
Microsoft: Aitp://uddi.microsoft.com/ inquire 

— accesarea interfetei de publicare pentru registrul de tip UBR de la Microsoft: 
hitps:/ [ uddi.microsoft.com/ publish 


Sunt disponibile si o serie de instrumente grafice de acces la UDDI prin 
interfețele prezentate mai sus. Menţionăm doar Registry Browser din cadrul 
pachetului de dezvoltare a serviciilor Web oferit de Sun — Java WSDP (Web 
Services Developer Pack). Tot în cadrul acestui pachet sunt disponibile o serie de 
exemple de programe Java pentru lucrul cu regiștrii UDDI publici. 


„Alte interfețe de programare 


O interfață de programare suplimentară este Security API, oferind două funcții: 


— discard_authToken — informează nodul că foken-ul (jetonul) de autentificare 
obţinut anterior nu mai este solicitat și că trebuie considerat invalid dacă este 
utilizat după ce acest mesaj este primit (astfel, se controlează maniera de 
valabilitate a procesului de autentificare); 

— get_authToken — solicită de la un nod UDDI un jeton de autentificare sub 
forma unui element az/hInfo. Un astfel de element poate fi solicitat atunci 
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cand se folosesc funcţii din alte interfeţe de programare precum Inquiry, 
Publication, Custody and Ownership Transfer saa Subscription. 


Interfata de programare numita Custody and Ownership Transfer API permite ca 
orice nod al unui registru să transfere „custodia” unei structuri businessEntity sau 
tMode/ de la un nod la altul. De asemenea, se oferă suport si pentru preluarea de 
la o entitate la alta a dreptului de proprietate asupra acestor structuri. 

Fără a intra în detalii tehnice — pe care le puteţi găsi în specificaţiile UDDI — 
să urmărim un scenariu general. Să consideram că avem la dispoziţie un registru 
UDDI format din nodurile A, B și C. Registrul permite fiecărui nod să-și 
definească propriile reguli pentru înregistrare, autentificare și autorizare. Dacă o 
persoană P dorește să se autentifice, va trebui să obțină regulile de politică a 
accesului ale celor trei noduri. Să considerăm cazul în care P alege nodul A. 

Dacă reușește să se autentifice cu succes si să publice o entitate business (fie 
ea desemnată de E,), atunci P devine proprietar (owner) al lui E}. Se consideră cá 
nodul A este custode (custodian) pentru E,. De asemenea, P poate efectua aceleaşi 
operaţii la nodul B, fiind în măsură să publice o entitate de afaceri E,. Nu se 
poate face nici o presupunere că un registru UDDI (sau nodurile sale) este 
„conştient” cá P reprezintă aceeași persoană. P este responsabil pentru menti- 
nerea identităţii și autentificării corecte pentru fiecare nod din cadrul registrului. 

Interfața Subscription API dă posibilitatea clienţilor autentificaţi să primească 
informaţii privitoare la schimbările registrilor UDDI de care aceștia sunt inte- 
resati. Această interfaţă este opţională și poate fi implementată în maniera dorită 
la nivelul fiecărui nod. 


1.7. UDDI şi SOAP 


Vom enumera in cele ce urmează convențiile utilizării SOAP si UDDI, pre- 
zentând ce elemente ale protocolului SOAP 1.1 sunt suportate sau nu de UDDI: 


e UDDI necesită prezenţa câmpului SOAPAcfon din antetul HTTP. SOAPAction 
poate conţine o valoare sau poate fi vid: 


POST ... HTTP/1.1 

Host: www.portocale.info 

Content-Type: text/xml; charset-"utf-8" 
Content-Length: NNNN 

SOAPAction: "" 


<?xml version="1.0" encoding-"UTF-8" ?> 
«Envelope xmlns-"http://schemas.xmlsoap.org/soap/envelope/"» 
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<Body> 
<get_bindingDetail xmlns="urn:uddi-org:api_v3"> 


</Envelope> 

* UDDI nu oferă suport pentru conceptul de actor SOAP (pentru SOAP 1.2, 
regăsit sub numele de rol — rok). Nodurile UDDI vor respinge orice cerere 
care vine cu un atribut actor în elementul Header. Se va întoarce o eroare 
SOAP fără nici un element De/a//, iar codul erorii este de tip Chent (sau Sender 
în cazul SOAP 1.2). 

* UDDI nu are prevăzut suport pentru facilitatea SOAP Encoding. În mesajele 
trimise unui nod UDDI, nu trebuie să existe nici o informaţie privitoare la 
stilul de codificare pentru nici un element din cadrul spaţiului de nume 
urn:uddi-org. În caz contrat, nodul va răspunde cu un cod de eroare de tip 
Client, iar faultstring va indica motivul apariţiei problemei. 

e Regiștrii UDDI pot ignora conţinutul anteturilor SOAP. 

e UDDI suportă următoarele coduri de eroare SOAP 1.1: VersionMismatch, 
MustUnderstand, Client şi Server. 


1.8. UDDI și WSDL 


UDDI este o arhitectură care permite stocarea informaţiilor privitoare la diferite 
servicii Web, însă nu se ocupă cu descrierea acestora. Pentru a putea utiliza un 
serviciu Web regăsit prin intermediul UDDI, avem nevoie de o descriere WSDL 
a acestuia. În cele ce urmează, ne vom referi la WSDL 1.1, modificările în cele 
ce priveşte versiunea 2.0 fiind minore. 

Specificatiile existente descriu câteva tipuri de structuri ZModel, care trebuie să 
fie furnizate de regiștrii UDDI, astfel încât să putem avea suport pentru a 
modela informaţii de tip por/Dype si binding din WSDL la nivel UDDI. De 
asemenea, trebuie furnizat un model care să fie consistent atunci când se 
lucrează atât cu versiunea 3.0, cât și cu UDDI 2.0. Mai mult, surprinderea 
informaţiilor dintr-o WSDL trebuie să se realizeze fără o duplicare excesivă. 

Sunt introduse şase așa-numite sisteme categoriale (category systems): 


1. WSDL Entity Type Category System — este folosit pentru a identifica entitățile 
UDDI care corespund celor WSDL. Este în mod obișnuit folosit în cazul 
structurilor ‘Model si businessService. Cum WSDL permite ca por/Iype si un 
binding sa aiba acelasi nume, singurul mod de a diferentia cele doua elemente 
tModel — corespunzătoare informaţiilor porfLype şi, respectiv, binding — este de 
a recurge la keyedReference. 
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XML Namespace Category System — este utilizat la reprezentarea oricărui spațiu 
de nume XML (nu doar pentru spaţii de nume privitoare la WSDL). Această 
facilitate permite realizarea de interogări precise, folosindu-se numele complet 
al elementelor XML (spaţiu de nume + numele local de element). 


„ XML Local Name Category System — poate fi util atunci când se foloseşte numele 


local al unui element XML, pentru cazul în care numele corespunzând unei 
structuri UDDI nu poate fi același cu cel al unui element XML local (fără a 
fi prefixat de spaţiul de nume). 

WSDL portlype Reference Category System — este folosit pentru a reprezenta 
legătura dintre un binding si un port Type. I se permite unei entități UDDI să se 
refere la o alta entitate prin stocarea cheii sale ca valoare a atributului 
keyValue al lui ReyReference (privitor la acest sistem de clasificare). 

Protocol Category System — permite ca structuri /Mode/ referitoare la protocoale 
definite de utilizator să fie încorporate în abordarea descrisă în specificații. 
Transport Category System — permite ca structuri ZMode/ de transport specificate 
de utilizator sá poate fi folosite in acest context. 


De asemenea, se mai poate recurge si la următoarele tipuri de structuri Model: 


SOAP Protocol (Model — pentru a reprezenta utilizarea SOAP si WSDL; 
HTTP Protocol (Model — pentru a modela legătura între WSDL si HTTP; 
WSDL Address tModel — pentru cazul in care se folosesc documente WSDL. 


Vom da o serie de detalii referitoare la legătura dintre WSDL si UDDI 2.0 


(diferenţele fata de versiunea 3 nu sunt semnificative). 


Un element portlype specific WSDL este reprezentat în cadrul UDDI de un 


tModel. Acest tModel este clasificat folosind WSDL Entity Type Category System. 
Numele structurii ZMode/ asociate lui porfT ype va fi identic cu cel al lui porz Type. 
Acest aspect eludează cumva specificaţiile UDDI care prevăd că numele unui 
tModel ar trebui să fie un URI. 


Când s-a luat această decizie s-au propus următoarele alternative: 


să se folosească numele lui porflype — varianta aleasă; 

să se recurgă la o combinaţie dintre porflype si spaţiul de nume. Această 
opţiune ar fi făcut mai dificilă căutarea fie după spaţiul de nume, fie conform 
unui port Type; 

să se utilizeze un URI si numele local al elementelor XML, iar spațiul de 
nume să fie plasat in sub-elementul categoryBag din 7Mode/. Această variantă 
face si mai dificilă căutarea numelui unui porfT ype, iar numele /Mode/-ului nu 
conţine nici o informaţie reprezentativă. 
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Spaţiul de nume al elementului porfT ype este dat de ReyedReference din marcatorul 
categoryBag al structurii Model privitoare la port ype. Acest ReyedReference determină 
legătura cu sistemul de clasificare XML Namespace menţionat mai sus. 

Elementul binding este reprezentat tot ca un 7Mode/, dar de tip WSDL 
binding tModel, pentru a-l distinge de alte categorii de structuri 7Mode/, Se 
folosește același sistem de clasificare ca și în cazul anterior, dar cu o valoare 
diferită pentru keyValue. Numele 7Mode/-ului este același cu cel cuprins de 
binding. 

Elementul service al documentului WSDL este reprezentat de businessService. 
Daca service desemnează interfaţa unui serviciu Web prezent deja în cadrul 
registrului UDDI, atunci structura businesService aferentă este adăugată infor- 
matiilor existente. În caz contrar, poate fi creată o nouă intrare businessService. 

Elementul port este reprezentat de bindingTemplate. Conţinutul relației dintre 
un serviciu WSDL si porturile sale este oglindit aici de relația dintre businessService 
si binding l'emplates. 

Discutia de mai sus se concretizeazá in figura urmátoare. 


portType tModel 


tModel 


bindingTemplate 


businessService 


Figura 4. Relația dintre elementele WSDL si cele UDDI 


Publicarea si găsirea descrierilor WSDL 


O descriere WSDL completă a unui serviciu este o combinaţie între documentul 
de tip interfaţă a serviciului și documentul de tip implementare. 

Cum interfaţa serviciului reprezintă o definiţie reutilizabilă a acestuia, ea este 
publicată într-un registru UDDI ca un ‘Mode/. Implementarea serviciului descrie 
o instanță a acestuia. Fiecare instanţă este definită folosind elementul WSDL 
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service. Pentru a publica o structură businessService este utilizat un element service 
dintr-un document de tip implementare. 

Figura 5 oferă o serie de detalii privind asocierea elementelor WSDL ca 
elemente UDDI. 


Document WSDL descriind 
implementarea serviciului 


<import> j businessEntity 


<service> businessService 


<port> bindingTemplate 


bindingTemplate 


Document WSDL descriind 
interfața serviciului 


<types> 
<message> 

<portType> 
<binding> 


tModel 


Figura 5. Corespondenta dintre elementele WSDL 
şi intrările UDDI 


Structura /Mode/ corespunzătoare interfeţei serviciului Web este publicată de 
furnizorul acelei interfeţe de serviciu. O parte dintre elementele din “Mode/ sunt 
construite pe baza informaţiilor din descrierea WSDL aferentă. În tabelul următor 
se definesc pașii creării unui ZMode/ care pentru a fi valid ar trebui numit folosind 
targetNamespace şi ar trebui să conţină date pentru „umplerea” elementelor 
overviewURL si category Bag. 
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tModel 
UDDI 


description 


overviewURL 


category Bag 


Interfața 
WSDL a 
serviciului 
Atributul 
targetNamespace 


pentru definirea 
elementului 


Elementul 
documentation 


URI-ul interfeţei 
setviciului si 
specificarea 
elementului binding 


Descriere 


Numele pentru ZMode este obţinut 
folosindu-se valoarea atributului 
targetNamespace din documentul 
WSDL. Este necesar un nume con- 
sistent, pentru ca un ZMode/ să fie loca- 
lizat folosindu-se doar informatii din 
documentul de tip implementare a 
serviciului. 

Elementul description din Model este 
restrâns la 256 de caractere. Daca ele- 
mentul documentation nu exista, atunci 
trebuie utilizat numele atributului din 
elementul definitions. 


Localizarea documentului de tip inter- 
fata a serviciului poate fi folosită ca 
valoare pentru overviewURL. Dacă 
există mai mult de un singur element 
binding, atanci valoarea acestuia este 
codificată în URL. 


Elementul category Bag trebuie să 
conţină cel puţin un sub-element 
ReyedReference. Atributul key Name va 
avea valoarea zddi-org:fypes, iar 

key Value va avea valoarea wsd/Spec. 


Obli- 
gatoriu 


Documentul de mai jos reprezintă interfaţa unui serviciu Web. Valorile ce vor 


fi inserate într-un ZMode/ apar cu caractere îngroșate: 


<?xml version="1.0"?> 


<definitions name="TranzactiiPortServic 


targetNamespace= 
"http: //www.portocale.info/ 
TranzactiiPortService-interface" 

xmlns:tns- 


"http://www.portocale.info/TranzactiiPortServic 


-interface" 


xmlns:xsd="http://www.w3.org/2001/XMLSchema" 


xmlns:soap-"http://schemas.xmlsoap.org/wsdl/soap/" 


xmlns-"http://schemas.xmlsoap.org/wsdl/"» 


«documentation xml:lang="ro"> 
Definitia unei interfete standard WSDL pentru 
un serviciu de tranzactii de portocale. 
</documentation> 


interface" 
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<message name="TipPortocaleRequest"> 
<part name="tip" type="xsd:string"/> 
</message> 


«message name="TipPortocaleResponse"> 

<part name-"tipIntors" type="xsd:string"/> 
</message> 
<portType name="TipPortocaleTranzactiiPortService"> 


<operation name="furnizeazaTipPortocale"> 
<input message="tns:TipPortocaleRequest"/> 
<output message="tns:TipPortocaleResponse"/> 
</operation> 
</portType> 


<binding name="TipPortocaleBinding" 
type="tns:TipPortocaleTranzactiiPortService"> 
<soap:binding style="rpc" transport= 
"http://schemas.xmlsoap.org/soap/http"/> 
<operation name-"furnizeazaTipPortocale"» 
<soap:operation soapAction= 
"http://www.portocale.info/furnizeazaTip"/> 
<input> 
<soap:body use="encoded" 
namespace="urn:tip-portocale-tranzactii-port" 
encodingStyle= 
"http://schemas.xmlsoap.org/soap/encoding/"/> 
</input> 
<output> 
<soap:body use="encoded" 
namespace="urn:tip-portocale-tranzactii-port" 
encodingStyle= 
"http://schemas.xmlsoap.org/soap/encoding/"/> 
</output> 
</operation> 
</binding> 


</definitions> 


Valoarea atributului sargetNamespace va fi folosită ca nume pentru ‘Model, 
conţinutul elementului documentation va reprezenta descrierea structurii ZMode/, iar 
atributul zzzze al elementului binding va fi utilizat să descrie overviewURL. 

Documentul UDDI privitor la ZMode/ are forma următoare: 

<?xml version="1.0"?> 

<tModel tModelKey=""> 


<name>http: //www.portocale.info/ 
TranzactiiPortService interface</name> 


DESCOPERIREA SERVICIILOR 165 


<description xml:lang="ro"> 
Definitia unei interfete standard WSDL pentru 
un serviciu de tranzactii de portocale. 
</description> 


<overviewDoc> 
<description xml:lang="ro"> 
Documentul WSDL descriind interfata serviciului 
</description> 
<overviewURL> 
http://www.portocale.info/TranzactiiPortService- 
interface.wsdl#TipPortocaleBinding 
</overviewURL> 
</overviewDoc> 


<categoryBag> 
<keyedReference tModelKey-"uuid:..." 
keyName="uddi-org: types" keyvalue="wsdlSpec"/> 
<keyedReference tModelKey-"uuid:..." 
keyName="Serviciu tranzact." keyValue="..."/> 
</categoryBag> 
</tModel> 


Elementul overviewURL are valoarea hitp:// www portocale.info/ TranzactiiPortS ervice- 
-interface.wsdl, cate reprezintă adresa documentului WSDL de tip interfață a 
serviciului Web. El conţine, de asemenea, o referinţă directă la elementul binding 
cu name="TipPortocaleBinding" în documentul de tip interfaţă a serviciului 
Cum există doar un singur element binding în documentul WSDL, această 
referință la binding nu este obligatorie. 

Implementarea serviciului Web este publicată în regiștrii UDDI ca o structură 
businessService, având unul sau mai multe marcaje bindingTemplates. Această publi- 
care este realizată de furnizorul acelui serviciu. 

Pentru fiecare element service specificat în documentul de implementare a 
serviciului va fi creată câte o structură businessService. 

Lista de sub-elemente ale businessService care pot fi specificate pe baza 
conţinutului documentului WSDL de implementare a serviciului cuprinde: 


— name — are valoarea dată de atributul elementului service din documentul 
WSDL; 


— description — foloseste primele 256 de caractere ale elementului documentation, 
daca exista. 


Pentru fiecare port din cadrul elementului service se creează un nou element 
bindinglemplate, conform detaliilor din tabelul următor. 
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binding 
Template 
description Dacă elementul port contine un sub-element documen- 
tation, descrierea conţine primele 256 de caractere ale 
elementului documentation 


accessPoint Pentru o legare (binding, SOAP sau HTTP, accessPoint 
ate valoarea atributului /ocation al elementului extension 
asociat elementului port. Dacă elementul conţine un 
URL, atributul URLType va desemna protocolul din 
cadrul URL-ului. Dacă nu se folosește nici un URL, 
atributul URLT)pe ar trebui folosit pentru a se cunoaște 
tipul protocolului. 


Descriere 


tModel Va exista câte un element ¢Mode/InstancelInfo pentru fie- 
Instancelnfo | cate tMode/ pe care-l referentiaza. Astfel, va apărea cel 
putin un ZMode/InstanceInfo incluzând o referință directa 
la *Mode/-ul ce reprezintă documentul de interfață a 
serviciului. 


overviewURL | Poate contine o referință directă la documentul de 
implementare a serviciului, folosită doar pentru a 
furniza o documentaţie uşor de înţeles (human-readable). 
Toate celelalte informaţii din acest document ar trebui 
să fie accesibile printr-o entitate de date UDDI (UDDI 
data entity). Suntem asiguraţi că documentul publicat 
este acelaşi cu cel obţinut în urma operaţiei de căutare. 
Dacă acest document cuprinde mai mult decât un ele- 
ment port, atunci acesta ar trebui să conţină o referință 
directă la atributul mame al lui port. Nu este suficient să se 
folosească doar o referinţă la elementul binding din 
tMode/, deoarece pot exista mai multe marcaje port 
referind acelaşi binding. 


Exemplul de mai jos reprezintă un document WSDL de implementare a unui 
serviciu. Valorile indicate cu caractere îngroșate sunt obligatorii pentru crearea 
intrărilor businessService si binding Templates. 


<definitions name="TranzactiiPortService" 
targetNamespace= 
"http://www.portocale.info/TranzactiiPortService" 
xmlns:interface- 
"http://www.portocale.info/ 


TranzactiiPortService-interface" 
xmlns:xsd-"http://www.w3.org/2001/XMLSchema" 
xmlns:soap-"http://schemas.xmlsoap.org/wsdl/soap/" 
xmlns-"http://schemas.xmlsoap.org/wsdl/"» 
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<import namespace="http://www.portocale.info/ 


TranzactiiPortService-interface" 
location= 
"http: //www.portocale.info/wsdl1/ 
TranzactiiPortService-interface.wsdl"/> 


<service name="TranzactiiPortService"> 
<documentation>...</documentation> 
«port name="TipPortocaleServicePort" 
binding="interface:TipPortocaleBinding"> 
<documentation> 
TipPortocaleTranzactiiPortService 
</documentation> 
<soap:address location= 
"http://www.portocale.info/TranzactiiPortService"/> 
</port> 
</service> 
</definitions> 


Atributul pape al elementului service va fi folosit ca nume pentru businessService. 
Elementul documentation din interiorul elementului service este utilizat pentru a 
descrie structura businessService. 

Atributul pape al elementului port este anexat lui overviewURL, care contine o 
referință la documentul de implementare a serviciului. Atributul /ocation al lui 
service este folosit pentru „umplerea” marcatorului accessPoint din structura 
binding l'emplate. 

Definiţia unei intrări businessDefinition create pe baza documentului WSDL de 
mai sus este furnizată de exemplul următor. Elementul cafegoryBag ar trebui să 
conţină unul sau mai multi marcatori AeyedReference, folosiți in clasificarea 
scopurilor afacerilor utilizate pentru serviciul de fata. 

<businessService businessKey="..." serviceKey="..."> 


<name>TranzactiiPortService</name> 
<description xml:lang="en"> 


</description> 
<bindingTemplates> 
<bindingTemplate bindingKey="..." serviceKey="..."> 


<description> 


</description> 
<accesssPoint URLType="http"> 
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http://www.portocale.info/TipTranzactiiPort 
</accessPoint> 
<tModelInstanceDetails> 
<tModelInstancelnfo tModelKey="..."> 
<instanceDetails> 
<overviewURL> 
http://www.portocale.info/services/ 
TranzactiiPortService.wsdl 
</overviewURL> 
</instanceDetails> 
«/tModelInstanceInfo» 
</tModelInstanceDetails> 
</bindingTemplate> 
</bindingTemplates> 


<categoryBag> 

<keyedReference tModelKey="uuid:..." 

keyName-"..." keyValue-"..." /> 
</categoryBag> 

</businessService> 


Atributul 7Mode/Key are drept valoare un UUID pentru ‘Mode/-ul privitor la 
documentul de interfaţă a serviciului. Acest ZMode/ poate fi localizat folosindu-se 
atributul namespace din cadrul elementului zzport. Marcatorul overviewURL repre- 
zintă locaţia documentului care implementează serviciul. El nu conţine o referință 
la elementul port, deoarece este unic pentru acest document. 

Găsirea descrierilor WSDL privitoare la interfaţa serviciilor se realizează după 
cum urmează. După cum deja cunoaștem, toate documentele WSDL referitoare 
la interfața serviciilor Web sunt publicate în regiștrii UDDI sub formă de ZMode/. 
Fiecare structură 7Mode/ e clasificată într-o anumită manieră via category Bag. 
Operația find_tMode/ oferită de API-ul UDDI poate fi folosită pentru a găsi un 
¿Model clasificat. Localizarea tuturor descrierilor WSDL privitoare la interfața 
unui serviciu se realizează conform construcției următoare: 

«find tModel generic-"2.0" xmlns-"urn:uddi-org:api"» 

<categoryBag> 
<keyedReference tModelKey-"uuid:..." 


keyName="uddi-org:types" 
keyValue="wsdlSpec" /> 


</categoryBag> 
</find_tModel> 


Operația find_tModel va întoarce o listă de chei /Mod/. Folosindu-se metoda 
get_tModelDetail, este obţinută o descriere particulară a interfeţei unui serviciu. 
Metoda get zModelDetail va returna un element 7Mode/ precum cel prezentat in 
cadrul capitolului de fata. 
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Următorul pas este să se recurgă la elementul overviewURL pentru a se obţine 
conţinutul documentului WSDL de interfaţă a serviciului. 

In plus, în cadrul categoryBag se mai pot adăuga elemente keyedReference 
suplimentare pentru a se limita mulțimea de structuri ZMode/ întoarse ca răspuns 
la această cerere. Metoda find_tMode/ de mai sus poate fi folosită pentru a localiza 
toate serviciile de tip ,,TranzactiiPort” care folosesc WSDL. 

«find tModel generic="2.0" xmlns-"urn:uddi-org:api"» 

<categoryBag> 

<keyedReference tModelKey="uuid:..." 
keyName="uddi-org:types" 
keyValue="wsdlSpec" /> 

«!-- inserám un criteriu suplimentar de căutare --> 

<keyedReference tModelKey="uuid:..." 
keyName="TranzactiiPort" 
keyValue="..." /> 


</categoryBag> 
</find_tModel> 


Găsirea descrierilor WSDL privitoare la implementarea serviciilor Web se 
efectuează conform etapelor descrise în continuare. O implementare a unui 
serviciu este publicată in regiștrii UDDI ca o intrare businessService. Acest 
businessService va contine unul sau mai multe elemente LindingTemplates. 

Suplimentar, structurile businessService au asociate categorii de clasificare, atfel 
încât să poată fi identificate ca descrieri bazate pe WSDL a serviciilor. 

O soluţie pentru regăsirea descrierii unui serviciu este dată de operația 
find_service. 

O anumită entitate businessEntity se poate folosi de mesajul următor pentru 
localizarea unei structuri de tip businessService, incluzând implementarea unui 
serviciu ,,TranzactiiPort”. În plus, pot fi adăugate si alte elemente AeyedReferences 
în cadrul categoryBag, cu rol de filtrare a răspunsului. 

«find service businessKey-"..." generic="2.0" 

xmlns-"urn:uddi-org:api"» 
<categoryBag> 
<keyedReference tModelKey="uuid:..." 


keyName-"TranzactiiPort" 
keyValue="..." /» 


</categoryBag> 
</find_service> 


Metoda find servire poate fi de ajutor si pentru a localiza date de tip businessService, 
desemnând implementări specifice ale interfeţei unui serviciu. Mesajul descris 
mai jos contine un exemplu in care se caută toate elementele businessService din 
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cadrul marcajului businessEntity. Acest din urmă element referă implementarea 
interfeţei unui serviciu particular (de exemplu, privitor la tranzacţiile bancare). 
Cum interfața unui serviciu este reprezentată de un ‘Model, se va folosi un 
tMode/Bag pentru a menţiona cheia ZMode/ corespunzătoare interfeţei WSDL a 
serviciului considerat. 


«find service businessKey-"..." generic="2.0" 
xmlns-"urn:uddi-org:api"-» 
<tModelBag> 
<!-- cheia tModel-ului pentru interfata 
serviciului Web --> 
<tModelKey>...</tModelKey> 
</tModelBag> 


</find_service> 


Metoda find service va returna o lista de intrări. Descrierea businessService poate 
fi obţinută folosind metoda get_serviceDetail. Aceasta va întoarce o structură 
businessService precum cea prezentată mai sus. După ce s-a obţinut un businessService, 
pentru invocarea serviciului Web găsit se va selecta un anumit element bindingTemplate 
inclus in businessService. Elementul accessPoint din cadrul marcatorului bindingTemplate 
semnifică tocmai punctul terminal al serviciului. 

De asemenea, poate fi folosit elementul overviewURL, în vederea obţinerii 
conţinutului documentului WSDL referitor la implementarea serviciului, care la 
rândul său poate oferi și alte detalii de interes. 

Furnizăm în continuare maniera de găsire a unei structuri bindingTemplate. Daca 
marcatorul businessService are mai mult de un element bindingTemplate, este dificil să 
se determine care marcaj binding lewp/are trebuie efectiv folosit. Pentru a localiza 
elementul bindingTemplate ce ar trebui utilizat, vom recurge la operaţia find_binding. 

Exemplul de mai jos recurge la find_binding pentru a obţine elementul 
bindingT emplate, referentiind un anumit 7Mode/. Acest tMode/ poate fi asociat unui 
element binding particular din cadrul descrierii WSDL a interfeţei serviciului. 


«find binding serviceKey-"..." generic="1.0" 
xmlns-"urn:uddi-org:api"-» 
<tModelBag> 
<!-- cheia corespunzătoare 
interfeței serviciului ==> 
<tModelKey>...</tModelKey> 
</tModelBag> 


</find_binding> 


Se va obţine unul sau mai multe elemente bindingTemplate. După accesarea 
marcajului bindingTemplate, punctul de destinaţie pentru serviciul Web este oferit 
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de elementul accessPoint. Dacă elementul bindinglemplate a fost creat pe baza unui 
document WSDL existent (privitor la implementarea serviciului), atunci overview URL. 
poate oferi o referință la acest document. Acest document WSDL poate fi 
accesat pentru a obţine și alte informaţii utile privitoare la serviciul Web, 
informaţii care nu au putut fi regăsite în regiștrii UDDI. 

lată un exemplu de structură bindingTemplate întoarsă în urma interogării 
descrise anterior: 


<bindingTemplate bindingKey=""ServiceKey=""> 
<accesssPoint URLType="http"> 
http://www.portocale.info/TipTranzactiiPort 


</accessPoint> 
<tModelInstanceDetails> 
<!-- tModelKey include o cheie corespunzătoare 
interfetei serviciului --> 
<tModelInstancelnfo tModelKey="..."> 
<instanceDetails> 
<overviewURL> 
http://www.portocale.info/TranzactiiPortService.wsdl 
</overviewURL> 


</instanceDetails> 
</tModelInstanceInfo> 
«/tModelInstanceDetails» 
</bindingTemplate> 


1.9. Crearea propriului registru UDDI folosind jUDDI 


După cum am văzut mai sus, UDDI definește un protocol de descoperire a 
serviciilor Web (permiţând clienţilor să regăsească serviciile Web dorite), punând 
la dispoziţie şi un format standard de descriere a serviciilor (care oferă clienților 
detaliile privitoare la functionalitatile serviciilor Web găsite). 

Există două tipuri de registri UDDI: regiștrii publici si cei privaţi. In această 
secțiune vom detalia în principal maniera de manipulare a registrilor privati ce 
pot fi utili în cadrul unui mediu de tip enterprise. De asemenea, vom oferi o serie 
de amănunte privitoare la un cadru de lucru folosit pentru a reprezenta structuri 
ale registrilor UDDI si pentru a implementa registri UDDI privaţi. Este vorba 
de framewor&-al jUDDI, disponibil în regim open source. 


Descriere succintă a instrumentului jUDDI 


Instrumentul /UDDI este implementat în Java si oferă compatibilitatea cu UDDI 
versiunea 2.0 pentru managementul regiștrilor UDDI. 
Pentru a putea crea propriul registru UDDI, trebuie instalate următoarele aplicaţii: 
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Java 2 SDK — in exemplificarile urmatoare am folosit Java 2 SDK SE, 
versiunea 1.5.0_06; 

J2EE Build and Runtime Environment — s-a utilizat Java 2 Enterprise Edition (J2EE) 
1.4 oferit de Sun; 

Un server Web și/sau un container de servlet-uri — in acest caz s-a recurs la 
Apache Tomcat, versiunea 5.5.12; 

Un cadru de lucru pentru procesarea mesajelor SOAP — s-a folosit Apache 
Axis (compatibil cu /UDDT). 

Un mecanism de stocare a datelor — s-a utilizat serverul de baze de date 
MySQL versiunea 5.0 (se poate recurge, de asemenea, si la alte soluții, 
eventual comerciale: DB2, Sybase etc.); 

Un instrument de management al registrilor UDDI — în cazul nostru, am 


adoptat /UDDI. 


Aplicația jUDDI folosește Apache Axis pentru manipularea mesajelor SOAP. 


„Axis defineşte un cadru de transport transparent, care permite folosirea diferitelor 
protocoale. Pentru transferul mesajelor via HTTP, orice serviet derivat din clasa 
org.apacbe.axis.transport. btip.AxisServler este un bun candidat. 


În /UDDI există disponibile trei ser/e-uti ce extind clasa AxisServlet: 


org.apachejuddi.transport.axis. AdminServiet — pentru administrare; 
org.apachejuddi.transport.axis.PublishServiet — pentru publicarea in registri; 
org.apachejuddi.transport.axis. InguiryServiet — pentru realizarea interogárilor. 


Aceste trei clase sunt înregistrate de 7UDDI ca serviet-uri cu ajutorul unei aplicații- 


-server si sunt folosite doar pentru a determina tipul cererilor care sunt efectuate. 
Procesarea de fapt este realizată de către clasa org. apache juddi.transport.axis.AxisHandker. 


Instrumentul jUDDI încapsulează structurile de date fundamentale UDDI 


(businessEntity, businessService, bindingTemplate si tModel, in clase. Acestea se găsesc 
in pachetul org.apachejuddi.datatype sub următoarele denumiri: 


org.apache.juddi. datatype. business. Business Entity; 
org.apachejuddi.datatype. service. Business ervice, 
org.apachejuddi.datatype. binding. Binding emplate; 
org. apache juddi.datatype.tmodel. TModel. 


Pentru a putea procesa cererile clienţilor, nu avem de făcut decât să recurgem 


la instanţele acestor clase, împreună cu alte tipuri de date furnizate de mediul 


jUDDI. 
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Manipularea cererilor via jUDDI 


JUDDI despacheteazá un mesaj de cerere cu ajutorul unui obiect numit AxisHland/er. 

Clasa AxisHandler folosește serviciile clasei RegrstryEngine pentru a efectua proce- 
sarea efectivă a cererii primite. Modul de departajare a tipurilor de cereri (inquiry, 
publish şi admin) se realizează prin intermediul unui URI în cadrul AxzsServier. 
Framework-ul clasifică fiecare cerere în raport cu valoarea proprietății găsită în 
obiectul de cerere MessageContext pentru cheia sransport.hitp.serviet. 

De exemplu, o cerere de publicare de date în regiștrii UDDI e desemnată de 
un URI de genul ///p:/ / localbost:8080/ juddi/ publish asociat servlet-ului responsabil 
cu aceasta: PublishServiet. După ce a primit o cerere, un obiect al clasei RegistryEngine 
convertește cererea UDDI bazată pe XML în obiecte Java (deserializare, unmarshalling). 
Se invocă obiectele Java si ulterior se convertește răspunsul (obiectele Java) 
într-un răspuns în format XML (serializare, marshalling). 

Similar, un URI de forma ///p:/ / localhost:8080/ juddi/ inquiry corespunde unui 
servlet de tip InguiryServiet. 


Modul de autentificare 


Framework-ul JUDDI recurge la org.apachejuddi.auth.AuthenticationFactory pentru a 
crea o instanță Awthenticator, cu scopul de a putea autentifica un client dat. 
AuthenticatorFactory este o implementare a modelului Factory şi se foloseşte pentru 
a realiza o implementare pentru interfața org.apache.juddi.auth.Authentiator. Dacă se 
foloseşte o valoare nulă, atunci AwthenticationFactory creează o implementare 
implicită pentru Authenticator — org.apachejuddi.auth.DefaultAuthenticator. Clasa Default- 
Auuthenticator nu aplică nici o restricţie de acces, deci se permit toate cererile. 

În general, sistemele construite pe baza /UDDI trebuie să ofere o imple- 
mentare pentru interfața Authenticator, care să realizeze procesul de autentificare 
dorit. Clasa care implementează Authentication este înregistrată printr-o intrare a 
fişierului de configurare juddi.properties. 


Crearea registrilor 


Aplicația /UDDI se instalează ca o aplicație Web (fişier .ear sau .war) si, în 
contextul dat de adresa hitp://gazda:port/juddi, se poate exploata oriunde există 
un server Web sau un motor de procesare a serv/er-urilor (servlet engine). 

Vom descrie în continuare pașii care trebuie parcurși pentru instalare. Pre- 
cizăm faptul că, pentru ca instalarea să reușească pe mașina dumneavoastră 
conform „reţetelor” furnizate mai jos, trebuie să recurgeti exact la versiunile de 
aplicaţii precizate. În cazul utilizării altor versiuni, vor fi necesare — eventual — 
configurări diferite. 
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Preluati de pe Web serverul Apache Tomcat (versiunea 5.5). După ce l-aţi 
instalat, testati funcţionarea lui la adresa itp:/ //oca/host:8080. 

Transferati apoi de pe situl Apache framework-ul jUDDI. Pentru exemplificările 
noastre am utilizat juddi.war, versiunea 0.7.0. 

Prin intermediul Tomcat Web Application Manager, incarcati juddi.war (a se vedea 
figura următoare). 


Display 

Welcome to Tomcat 

Tomcat Simple Load Balancer Example App 
Tomcat Manager Application 

JSP 2.0 Examples 

manager Tomcat Manager Application 


8 


> 
a 
3 
5 
© 


È 
© 


/serviets-examples Servlet 2.4 Examples 
Tomcat Documentation 
Webdav Content Management 


‘tomcat-docs 


$ 


= 
[1 
o 
Liz) 

f 


| 


Deploy directory or WAR file located on 


Context Path (optional): — | 


XML Configuration file URL: | 
WAR or Directory URL: | 


WAR file to deploy 


Select WAR file to upload |CAjuddi war 


JVM Version 
Apache Tomcat/5.5.12 1.5.0_06-b05 Sun Microsystems Inc. 


Figura 6. Interfata Web a programului de management al serverului Tomcat 


A 


In caz de succes, veti obtine un rezultat precum cel din captura-ecran de mai 
jos. 


jUDDI 


Figura 7. Inserarea cu succes a framework-ului jUDDI 
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Pentru a stabili fișierul de jurnalizare corespunzător aplicaţiei /UDDI, vom 
edita /og4j.properties (localizat, pentru Windows, în directorul ci Tomeat5.5\ webapps 
juddi \ conf N), astfel încât să includă și linia: 


| log4j.appender.juddilog.File=C:/Tomcat5.5/logs/juddi.log 


De asemenea, trebuie modificat și fișierul «\Tomcat5.5\ webapps\juddi\ WEB-INF\ 


web.xml pentru a contine si următoarele: 


<env-entry-name> 
log4j.propsFile 


«/env- 


n 


try-name> 


<env 


ntry-value> 


C:\Tomcat5.5\webapps\juddi\conf\log4j.properties 


</env-entry-value> 
<env-entry-name> 
juddi.propsFile 


</env-en 


try-name» 


<env 


ntry-value> 


C:\Tomcat5.5\webapps\juddi\conf\juddi.properties 


</env 


n 


try-value> 


Următorul pas este să instalați serverul MySQL (am lucrat cu versiunea 


5.0.18). Transferati apoi instrumentul MySOL Control Center, care este un client 


folosit pentru a crea si a interoga baza de date. 


În acest moment, trebuie să creăm baza de date folosită de /UDDI; va fi 


numită judd. Autentificarea la server se va realiza prin utilizatorul „roo7” cu 
parola „adria”. Încărcaţi fişierul c Tomcat5.5\ webapps\juddi\ ddl juddi_mysql.ddl 


într-o fereastră SQL si executați comenzile SQL pe care le conţine (a se urmări 


figura de mai jos). 


Pasul următor este executarea următoarei comenzi, care stabilește numele 


entității care va publica date în regiștrii privati UDDI: 


INS! 
(PUB 


„I SHI 


ERT INTO PUBLISH 


ER ID, PUB 


VALU! 


ES ( 


'juddi', 


ER 
iI SH 


ER NAM 


E, ADMIN) 


'Juddi user', 


"false'); 
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ial [juddi] Query Window 


Fi File Edit View Query Options HotKeys 


Egg Bv ck | alo co | X m I [s 


[ 

SERVICE. KEY VARCHAR(41) NOT NULL, 
CATEGORY. ID INT NOT NULL, 
TMODEL KEY. REF VARCHAR(41) NULL, 
KEY. NAME VARCHAR(255) NULL, 
KEY, VALUE VARCHAR(255) NOT NULL, 
PRIMARY KEY (SERVICE KEY,CATEGORY. ID], 
FOREIGN KEY (SERVICE KEY] 

REFERENCES BUSINESS SERVICE (SERVICE, KEY] 
jh 


CREATE TABLE SERVICE_NAME 


[ 
SERVICE KEY VARCHAR([41) NOT NULL. 
SERVICE NAME ID INT NOT NULL. 
LANG CODE VARCHAR(2) NULL, 
NAME VARCHAR(255)] NOT NULL, 
PRIMARY KEY (SERVICE KEY,SERVICE NAME. ID], 
FOREIGN KEY (SERVICE KEY] 
REFERENCES BUSINESS SERVICE (SERVICE KEY] 
); 


CREATE TABLE BINDING_TEMPLATE 
[ 
SERVICE KEY VARCHAR([41) NOT NULL, 


Ted Query 1 
x| | 35 UUEIP US; T TUW airected [U.U*] SEC 
| A Query DK, 1 row affected (0.04) sec 
| Ò Query OK, 1 row affected (0.06) sec 


Figura 8. Executia fişierului de comenzi SOL in vederea creării tabelelor 
ce urmează a fi folosite de jUDDI 


[7] Console Options HotKeys Window Help 


File Edit View Query Options HotKeys 


lg E - LE tK Re X | o o X mI [smi |)! m-a 


INSERT INTO PUBLISHER (PUBLISHER ID.PUBLISHER NAME ADMIN) VALUES f'juddi' Juddi user false’); 


Figura 9. Inserarea datelor privitoare la entitatea ce va publica date în regiștrii privați 
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Mai trebuie să obţineţi de pe Internet driver-ul MySQL JDBC, astfel încât să 
se poată accesa serverul MySQL. Preluati mysg/-connectorjava-3.0.17-stable-bingar ŞI 
copiati-l în directorul cNTomeat5.5 NcommonNbN. 


Configurarea si folosirea aplicației jUDDI 


Creați un fişier cu numele juddi.xmlin cadrul directorului e Tomcat5.5\ conf Catalina\ 
localhost\. Drept conţinut, introduceți următoarele linii: 


<Context path="/juddi" docBase="juddi" debug="5" 
reloadable="true" crossContext="true"> 


<Resourc 


name-"jdbc/juddiDB" auth="Container" 


</Context> 


type-"javax.sql.DataSource" 
initialSize-"30" maxActive-"100" 
maxIdle="30" maxWait-"10000" 
username="root" password-"adria" 
driverClassName-"com.mysql.jdbc.Driver" 
removeAbandoned-"true" 
removeAbandonedTimeout="60" 
logAbandoned-"true" 
url-2"jdbc:mysql://localhost:3306/juddi" /> 


Astfel, am stabilit o serie de parametri referitori la conexiunea cu serverul de 


baze de date via driver-ul mai sus menţionat. 


In cazul in care lucrati cu Tomcat versiunea 4.1.24, acest fisier are forma: 


«Context path="/juddi" docBase="juddi" debug="5" 
reloadable="true" crossContext="true"> 


<Logger 


className="org.apache.catalina.logger.FileLogger" 
prefix="localhost_juddiDB log" suffix=".txt" 
timestamp="true" /> 


<Resourc 


name="jdbc/juddiDB" 
auth="Container" 
type-"javax.sql.DataSource" /» 


<ResourceParams name="jdbc/juddiDB"> 


<parameter> 


<name>factory</name> 
<value> 


org.apache.commons.dbcp.BasicDataSourceFactory 


</value> 


</parameter> 
<parameter> 


<name>maxActive</name> 
<value>100</value> 
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</parameter> 
<parameter> 
<name>maxIdle</name> 
<value>30</value> 
</parameter> 
<parameter> 
<name>maxWait</name> 
<value>10000</value> 
</parameter> 
<parameter> 
<name>username</name> 


<value>root</value> 
</parameter> 
<parameter> 
<name>password</name> 
<value>adria</value> 
</parameter> 
<parameter> 
<name>driverClassName</name> 
<value>org.gjt.mm.mysql.Driver</value> 
</parameter> 
<parameter> 
<name>url</name> 
<value> 
jdbc:mysql://localhost:3306/jJUDDI?autoReconnect=tru 
</value> 
</parameter> 


</ResourceParams> 
</Context> 


Sunteţi in acest moment pregătiți sa rulati /JUDDI. 

Pentru a verifica modul de execuţie a instrumentului /UDDI, porniţi serverul 
Web și introduceți adresa /74p:/ //oca/host:8080/ juddi/ happyjuddijsp. Dacă obţineţi 
informaţii similare celor din figura de mai jos, atunci din acest moment registrul 
dumneavoastră UDDI este pregătit să receptioneze cereri. 

Pachetul de instalare /UDDI include o serie de alte exemple utile pe care le 
puteți folosi pentru a trimite cereri registrului. 

Folosind succesiunea de pași detaliată anterior, puteţi utiliza jUDDI pentru 
crearea altor registri privati UDDI, care să poată deservi cereri de publicare, 
autentificare și interogare. 

Nu ne rămâne decât să vă urăm succes în exploatarea registrului UDDI propriul 
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e jUDDI Happiness Page - Mozilla Firefox 


File Edit View Go Bookmarks Tools Help 
<a - m M E e http://127.0.0.1:8080/juddi/happyjuddi.jsp 


@ Getting Started GÀ Latest Headlines 


jUDDI 


Happy jUDDI! 
jUDDI DataSource Check 


got a JNDI Context! 
got a jUDDI DataSource! 
got a jUDDI db Connection! 


*** jUDDI Publishers *** 
Juddi user 


jUDDI Properties 


juddi.maxMessageSize: 2097152 
juddi.authFactory: org.juddi.auth.simple.SimpleAuthenticatorFactory 
juddi.uuidgenFactory: org.juddi.uuidgen.jvm.JavaUUIDGenFactory 


juddi.dataStoreFactory: org.juddi.datastore.jdbc.JDBCDataStoreFactory 


At 


juddi.maxNameLength: 255 
juddi.maxNameElementsAllowed: 5 
juddi.adminEmailAddress: admin@juddi.org 


i 
juddi.operatorName: jUDDI.org 


System Properties 


java.runtime.name: Java(TM) 2 Runtime Environment, Standard Edition 
sun.boot.library.path: C:\Java\jrei.5.0 06\bin 
java.vm.version: 1.5.0 06-b05 


Figura 10. Mesajele de stare obtinute în urma rulării aplicației de diagnosticare jUDDI 


2. WSIL (Web Service Inspection Language) 


Iniţiativa WSIL (Web Service Inspection Language) — regăsită si sub numele 
WS-Inspection — defineşte modul in care se poate descoperi o descriere XML a 
unui serviciu Web aflat pe un server Web. Astfel, serviciile Web pot fi regăsite 
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facil. Via WSIL, un furnizor de servicii poate să-și facă disponibile serviciile 
pentru a putea fi descoperite și utilizate de către consumatori. 

Acest aspect este similar cu misiunea UDDI, dar WSIL se dorește a fi o etapă 
superioară UDDI în evoluţia procesului de regăsire a serviciilor Web. 

Figura următoare ilustrează noile relaţii ce pot fi stabilite între consumatori, 
furnizori şi regiștrii centralizati UDDI. Prima diferență se materializează in 
faptul că o cerere de căutare a unui serviciu Web nu se realizează direct asupra 
registrilor centralizati UDDI. În schimb, căutarea este efectuată de către consu- 
matori direct la furnizorul de servicii. 

Conform acestui model, regiștrii UDDI centralizati si nemoderati vor deveni 
descentralizati si moderati. De observat, de asemenea, că nimeni nu împiedică 
furnizorii de servicii să-și înregistreze serviciile în cadrul registrilor UDDI si să 
redirecteze găsirea serviciului spre regiștrii UDDI. 


Ofertant al serviciului Web 


Specifică un serviciu local 


Figura 11. Furnizorii de servicii îşi fac serviciile cunoscute via W SIL 
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Trebuie să observăm că WSIL nu reprezintă un limbaj de descriere a serviciilor 
Web, această responsabilitate având-o în continuare WSDL. Limbajul WSIL este 
folosit doar pentru a face publice serviciile Web. 

Elementele limbajului WSIL aparţin spaţiului de nume desemnat de adresa 
hitp:/ / schemas.xmlsoap.org/ ws/ 2001 / 10/ inspection] . 

Documentul WSIL minimal constă dintr-un element-rădăcină service, care 
conţine un element description. Elementul service are rol de prezentare a serviciilor. 
Documentele WSIL nu sunt folosite doar pentru descrierea serviciilor Web via 
WSDL, astfel încât să poată fi utilizate și alte maniere de definire a serviciilor. 

Specificatiile WSIL definesc o serie de convenţii care să permită consu- 
matorilor să localizeze documentele WSIL pe orice sit Web (vezi si figura 11). 
Aceste convenţii presupun existența unui nume prestabilit al documentului 
WSIL si o manieră de legătură la un document WSIL. Numele prestabilit este 
inspection.wsil, Un document cu un astfel de nume ar trebui plasat în punctele de 
intrare cele mai vizitate ale unui sit Web. De exemplu, dacă un astfel de punct 
este hitp:/ /www.magazin-portocale.info/, atunci documentul WSIL ar trebui localizat 
prin Ditp:/ / wow. magazin-portocale. înfo/ inspection.wsdl. 

Însă foarte puţini furnizori ce recurg la WSIL vor oferi documentul WSIL la 
acest nivel. Putem să ne gândim că aceste documente WSIL pot fi regăsite destul 
de ușor cu ajutorul unor motoare de căutare precum Google sau Yahool. 

Având scopul de a permite furnizorilor să-și organizeze serviciile într-o 
manieră ierarhică, documentele WSIL pot fi interconectate. Aceasta se realizează 
prin prezenţa elementului Zvk. Un document WSIL poate avea un număr oricât 
de mare de legături, generându-se astfel o întreagă reţea de documente WSIL. 

Drept exemplificare, vom oferi un fragment din documentul WSIL pus la 
dispoziţie de situl XMethods, document localizat la adresa //p:/ / mw.xmetbods.net/ 
inspection.wsil. Arborele asociat din figura 12 a fost generat cu ajutorul instru- 
mentului oXygen XML Editor. 

În ciuda prezenţei registrilor UDDI, se remarcă existenţa unui ,,gol” (gap) 
interpus între furnizorii de servicii si consumatori. Specificatia WSIL propusă de 
IBM şi Microsoft încearcă să acopere acest gol, în timp ce UDDI se perfec- 
tioneazá si va deveni o soluție convenabilă mai ales în contextul enterprise. 
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Document - inspection.wsil 
=e inspection a 
H xmins http.//schemas xmlsoap.org/ws/200171 Diinspectiani 


-- Wa xmlns:wsiluddi httpischemas.xmlsoap.orgiws/2001/1 0/inspectionruddi/ 
H xmins:wsilxmethods http:ischemas.xmethods.netws/2001/1 Oinspection/ 


șa! service (ză 


&-« service (..) 
| Eee abstract (od 
T Provides a SOAP RPC interface to XMethods for query operations 
= description a 
~~ Ha location httpwwww.xmethods.netwsdiiquery.wsdl 
H referencedNamespace httpvischemas.xmlisoap.orgiwsdli 
Se description m" 


H referencedNamespace httpwww.xmethods.net/ 
=) e wsilxmethods:serviceDetailPage(...] 


13 location http vAwwwexmethods netve2ViewListing.po?keys 
SG wsilkmethads:servicelD m 
25703 
T 
HOS service = 
&-€« service (a 


Figura 12. Detalii privind un serviciu Web pus la dispozitie de XMetbods 
şi descris prin WSIL 
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*, IBM’s UDDI Business Registry: http:/ /www.uddi.ibm.com/ 

*, Instrumentul JUDDI: http:/ /ws.apache.org/juddi/ 

* Java Coffee-Break: http:/ /www.javacoffeebreak.com/ 

*, Microsoft's UDDI Business Registry: http:/ /uddi.microsoft.com/ 

*, Serverul Apache: http:/ /httpd.apache.otg/ 

* Situl dedicat dezvoltatorilor MySQL: http://dev.mysql.com/ 

* Situl dedicat serverului Tomcat. http:/ /jakarta.apache.org/tomcat/ 

* Situl dedicat serviciilor Web: http://www.websetvices.org/ 

* Situl Sun privitor la Java: http:/ /java.sun.com/ 

* Situl XML SOAP: http:/ /www.xmlsoap.org/ 

*, Source Forge: http://www.soutceforge.net/ 

*, UDDI (Universal Description, Discovery, and Integration): http:/ /www.uddi.otg/ 
*, WS-I (Web Services-Interoperability Organization): http:/ /www.ws-i.otg/ 
*, XMethods: http:/ /www.xmethods.net/ 


Capitolul 6 


Dezvoltarea si utilizarea serviciilor Web 


„Dacă teoria mea nu corespunde faptelor, cu atât 
mai rau pentru fapte.” 
(Georg Wilhelm Friedrich Hegel) 


1. Dezvoltarea si invocarea de servicii Web 
folosind instrumente open source 


1.1. Introducere 


In majoritatea cazurilor, serviciile Web funcţionează conform paradigmei client/ 
server: serverul rulează permanent, unul sau mai mulți clienți trimit spre acesta 
cereri SOAP printr-un protocol de transport (cel mai uzual, HTTP), iar serverul 
întoarce un răspuns. 

În cazul serviciilor Web, standardele sunt esenţiale pentru asigurarea inter-ope- 
rabilitátii. Asa cum s-a văzut în capitolele anterioare, codificarea conţinutului 
mesajelor vehiculate (cererea și răspunsul) prin SOAP adoptă formatul XML, iar 
descrierea serviciului Web se bazează pe limbajul WSDL. Eventual, pot fi atașate 
optional date codificate în stilul base64, folosind propunerea SwA (SOAP with 
Attachments), oti metoda standardizată, recomandată de Consorţiul Web - MTOM 
(Message Transmission Optimization Mechanism). Mecanismul de ataşare respectă 
bine-cunoscutele prevederi MIME (Multipurpose Internet Mail Extensions), larg 
folosite in cazul mesajelor de posta electronica. 

Trebuie să remarcăm încă o dată că nu există nici o restricţie în alegerea 
limbajului de programare în care se vor implementa serviciul Web și posibilii lui 
clienți (programe desktop, aplicaţii Web, alte servicii Web etc.). Indiferent ce 
limbaj, instrument, platformă sunt folosite, în esență dezvoltarea și utilizarea 
serviciilor Web prezintă aceleași caracteristici și adoptă sabloane de proiectare 
similare. 

Unele instrumente SOAP implementează propriul server Web, folosind HTTP 
(de exemplu, SOAP::Lite sau Mierosof? Visual Web Developer). Altele, precum 
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extensia Soap pentru PHP sau biblioteca gSOAP, presupun instalarea in cadrul 
unui server Web particular, astfel încât daemon-ul HTTP va manevra mesajele 
SOAP spre o componentă proxy, care realizează invocarea serviciului Web in 
manieră transparentă pentru programator. O serie de instrumente SOAP suportă 
un mecanism de transport configurabil care pemite selecţia, la nivel de aplicaţie, 
a protocolului de transport. Modulul SOAP::L zf, de pildă, oferă suport pentru 
HTTP, FIP, SMTP sau Jabber. 

Instrumentele SOAP furnizează o componentă proxy, menită a procesa si 
interpreta mesajul SOAP în vederea invocării codului aplicaţiei. Această 
componentă trebuie să aibă în responsabilitate recunoașterea stilului de codi- 
ficare, translatarea datelor din format nativ — de exemplu obiecte Java sau 
„NET - în XML (si invers), procesarea antetului din mesajul SOAP cu atributul 
mustUnderstand="true" etc. Atunci când o componentă proxy manevreazá un 
mesaj SOAP, va trebui să efectueze următoarele: 


* deserializarea mesajului, dacă este necesar, din format XML într-o formă 
adecvată pentru a-l putea analiza; 

* invocarea codului (a metodelor); 

e serializarea răspunsului primit in XML şi manevrarea lui în scopul trimiterii 
acestuia la emițător. 


În ciuda diferenţelor de implementare, instrumentele pentru dezvoltarea de 
servicii Web prin SOAP urmează același model. 

În cadrul acestui subcapitol ne propunem să detaliem modul de implementare 
si de invocare a unor servicii Web pe baza uneltelor open source existente pentru 
PHP și Perl. Pentru început, vom construi un server și un client SOAP simplu 
în PHP, utilizând extensia Soap disponibilă în versiunea 5 a acestui server de 
aplicaţii și, ca alternativă, biblioteca NwSOAP care poate fi folosită si in PHP 4. 
În partea a doua a acestui subcapitol ne propunem să scriem un serviciu Web 
oferind o interfață comodă pentru operaţiile uzuale realizate asupra resurselor 
unui sistem de fişiere aflat de distanţă. Pentru aceasta, vom recurge la modulul 
SOAP.:Lite, unul dintre cele mai cunoscute instrumente de dezvoltare în limbajul 
Perl a serviciilor Web si a clienţilor aferenti acestora. 


1.2. Furnizarea stocurilor de portocale via 
un serviciu Web scris în PHP 5 


Misiunea pe care o avem de realizat este ușor de îndeplinit. Trebuie să imple- 
mentăm un server SOAP care va oferi accesul la un serviciu Web, incluzând o 
singură metodă — furnizeaza Cantit(). Aceasta va avea ca parametru de intrare un 
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şir de caractere desemnând un sortiment de portocale si va returna cantitatea 
existentă, dacă acel sortiment există. Nu vom furniza o descriere WSDL asociată 
serviciului, invocarea putându-se realiza explicit, după cum vom vedea mai jos. 
Codul-sursă al acestui serviciu simplu este dat în continuare: 


<?php 

try { 
// nu oferim nici o descriere WSDL, 
// stabilim URI-ul serviciului 
Șserver = new SoapServer (null, 

array('uri' -» 'urn:portocale.info')); 

// adáugám metodele implementat 
Sserver->addFunction('furnizeazaCantit'); 
// aşteptăm cereri SOAP 


Sserver->handle(); 
catch (SOAPFault Sexception) { 
echo 'A apărut o excepţie: ' . Sexception; 


TS 


wa 


// funcţie care furnizează cantitatea 

// dintr-un sortiment de portocale 

function furnizeazaCantit (SnumeSortiment) { 
// de obicei, aici vom efectua o interogare SQL 
// ori una XQuery 
switch (SnumeSortiment) { 


case 'japoneze': return 33; 
case 'albastre': return 74; 
default : return 'inexistent'; 


} 
?2 


Primul argument al constructorului desemnează adresa (URL-ul) documentului 
WSDL ce descrie serviciul, in acest caz fiind zz/. Spaţiul de nume prin care e 
identificat serviciul dezvoltat este dat în situaţia de fata de un URN — zra:portocale.info. 
Fiecare funcţie implementată va fi adăugată cu addFunction(). De asemenea, unui 
serviciu i se poate asocia o clasă prin intermediul metodei se/C/ass(). Cererile 
SOAP vor fi rezolvate via handle(), care va avea în responsabilitate si (de)seria- 
lizarea datelor. 

Deoarece extensia Soap este inclusă în distribuţia standard PHP 5, pentru 
rularea programului de mai sus nu va trebui instalat nimic suplimentar. În 
exemplificările de fata am recurs la PHP versiunea 5.0.4 sub diverse versiuni ale 
serverului Apache 2.0. 
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1.3. Un client PHP pentru serviciul Web 
privitor la portocale 


Recurgând tot la extensia Soap, vom concepe un client care va invoca metoda 
expusă de serviciul Web pentru o serie de sortimente de portocale. Liniile de cod 
PHP sunt următoarele: 


try { 
Sclient = new SoapClient (null, 
array('location' -» 'http://localhost/sxml/ 
oranges-server.php', 
"uri! => 'urn:portocale.info')); 
// realizám o suită de invocári ale metodei dorite 


foreach (array('albastre', 'japoneze', 'celeste') 
as Ssortiment) { 
Șrez = $client->__call('furnizeazaCantit', 

array (Ssortiment) ); 
echo "<p>Stocul de portocale Ssortiment 
este <strong>Srez</strong>.</p>"; 
} 
} catch (SOAPFault Sexception) { 

echo 'A apărut o excepție: ' 

Sexception->faultstring; 


— 


Deoarece nu avem la dispozitie descrierea WSDL a serviciului, vom folosi 
__call() pentru invocarea metodei furnizeazaCantit(). Exceptiile ce pot surveni 
sunt capturate gratie construcţiei 77) ... catch incluse in PHP 5. Obiectul SOAPFauit 
încapsulează informaţiile privitoare la un fault SOAP; în cazul de fata am utilizat 
proprietatea faultstring pentru a afișa mesajul de excepţie. Esuarea unui apel 
SOAP poate fi verificată si cu îs_soap_fa4/4(). Mesajele vehiculate vor respecta in 
mod implicit versiunea 1.1 a protocolului SOAP. Extensia Soap oferă posibilitatea 
de a recurge însă și la SOAP 1.2. 

În urma iteratiilor realizate, vom obţine un rezultat precum cel din figura 1. 
Tipul răspunsului primit este unul eterogen (fie întreg, fie string), în funcție 
de existenţa sortimentului de portocale pentru care realizăm invocarea 
metodei. 
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©) Portocale - Mozilla Firefox 


File Edit View Go Bookmarks Tools Help 


@-®- = A c3 Că & | http: //endirra.ro/oranges-client. php {i © Go 
X Disable” [2] Cookies” 5.5 CSS» & Foms 7” Images (9 Informationr Miscellaneous” 


Stocul de portocale albastre este 74. 


Stocul de portocale japoneze este 33. 


Stocul de portocale celeste este inexistent. I 


Done oO É e D errors / 0 warnings 


Figura 1. Invocarea serviciului Web implementat ín PHP 5 


1.4. Un serviciu de manipulare a fişierelor implementat 
în Perl cu SOAP::Lite 


Ne propunem în continuare să implementăm un server SOAP, disponibil la 
portul 3333 via protocolul HTTP, care va incapsula functionalitatile unui serviciu 
Web, oferind diverse operaţii asupra fișierelor existente pe server. Drept exempli- 
ficare, vom scrie următoarele metode: 


— List, care furnizează lista fișierelor existente la nivel de server; nu necesită 
parametri de intrare și întoarce o structură de forma <file name-"..." /» 
pentru fiecare fişier găsit (vezi infra); 

— ChekIfExists, ce verifică existenţa unui fișier la nivel de server, având ca 
parametru de intrare un șir de caractere desemnând un nume de fișier; va 
întoarce valoarea 1 dacă fișierul există și 0 dacă e inaccesibil (nu poate fi 
regăsit ori nu există suficiente drepturi de acces asupra lui); 

— Rename, care redenumeste un fișier, necesitând doi parametri (numele vechi si 
cel nou) de tip sir de caractere; va întoarce un sir de caractere: „success? în caz 
de succes si „error” în caz contrat. 

Codul-sursă al programului Perl este următorul: 
+! /usr/bin/perl -w 


use strict; 
use SOAP::Transport::HTTP +debug => [qw(all)]; 


+ nu dorim să fim intrerupti de semnale 
+ precum "Broken pipe' ori la acţionarea 
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# combinatiei de taste CTRL+C 
SSIG{PIPE} = SSIG{INT} = 'IGNORE'; 


# initializám serverul, folosind un daemon HTTP 


my $server = SOAP::Transport::HTTP::Daemon->new ( 
LocalAddr => 'localhost', # adresa locala 
LocalPort => 3333, # portul utilizat 
Reuse => 1); + reutilizăm portul 


+ funcționalitatea serverului este furnizată 
+ de clasa 'XMLFiles' 
$server-»dispatch to ('XMLFiles'); 


print 'Serverul SOAP rulează la ' . $server-»url; 
# ne blocám, asteptánd cereri din partea clientilor 
Sserver->handle; 


+ clasa implementánd functionalit. serviciului Web 
BEGIN { 

package XMLFiles; 

use SOAP::Lite; 

use base qw(SOAP::Server::Parameters) ; 


sub List ( 4 metoda de generare a listei 

# fisierelor existente pe server 
my $self = shift; 
my Senvelope = pop; 


my $files = ''; 
returnăm răspunsul drept frag. de doc. XML 
foreach my $file (glob('*')) ( 
Sfiles .= "«file name=\"Sfile\" />"; 


return SOAP::Data->type('xml' => Sfiles); 


sub CheckIfExists { # metoda de verificare 
# a existentei unui fisier 
my $self = shift; 
my Senvelope = pop; 
+ preluám param. de intrare via o expresie XPath 
# (nu stim cum ar putea fi incapsulat) 
my $filename = Senvelope->dataof('//filename') ; 
# trimitem un 'fault' 
+ dacă nu există parametrul de intrare 
die SOAP: :Fault->faultcode ('Server.CheckIfExists!) 
->faultstring ( 
‘Input parameter is missing!) 


unless $filename; 
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+ furnizăm fişierul in cauză, dacă există 
return ( Sfilename->value) ? 1 : 0; 


sub Rename ( # metoda de redenumire a unui fisier 
my $self = shift; 


my Senvelope 


= pop; 


# preludm parametrii de intrare 
my $filenam 


= Senvelope->dataof('//filename') ; 


my Snewnam 
# eventual, 
die SOAP::Fault->faultcode('Server.Rename') 


= Senvelope-»dataof('//newname'); 


semnalăm inexistența lor 


->faultstring ( 


"Input filename parameter is missing!) 
unless $filename; 
die SOAP::Fault->faultcode('Server.Rename' ) 


->faultstring ( 


"Input newname parameter is missing!) 
unless Snewname; 
# returnám ráspunsul 


return SOAP::Data-»name('result' => 
(rename (Sfilename->value, $newname-»value) ? 
"success' : ‘'error')); 


# eventual, alte 


} 


metode... 


Serverul va rula la infinit, ocupand portul 3333 al masinii locale (vezi figura 2). 
Va pune la dispozitie via SOAP 1.1 peste HTTP cele trei metode descrise mai 
sus. Pentru fiecare metodă in parte, preluăm parametrii necesari. In cazul în care 


aceştia nu sunt furnizaţi de client, se va întoarce un mesaj de tip fau/t SOAP, 


semnalându-se o situație de excepţie. Am dorit ca răspunsul oferit să fie de mai 


multe tipuri de date (întreg, șir de caractere sau o listă de fişiere marcată în 


XML), pentru a se putea observa diferenţele de codificare. 

Modulul SOAP.:Per/ apare în majoritatea distributiilor Perl actuale. Versiunile 
utilizate pentru testarea si rularea exemplelor din această carte au fost 0.65 şi 
0.68. În cazul în care modulul este indisponibil, poate fi preluat din CPAN 
(Comprehensive Perl Archive Network) — accesibil la hitp://search.chan.org/ — şi instalat 
conform următorilor pași: 


info 


ias 


info 


infoiasi 


ias 


i)$ perl 
i)$ make 
$ make 


( 
( 
( 
( 


infoiasi 


) 
) 
1) 
) 


$ make 


Makefile.PL 


test 
install 
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busaco@localhost: /home/busaco/soap/xml-files/web-service . CD 
Session Edit View Bookmarks Settings Help 


[busaco@localhost web-service]$ perl xml-files.pl 
Serverul SOAP ruleaza la http://endirra:3333/J 


A dE Server | Æ| Client 


Figura 2. Ru/area serverului SOAP într-o fereastră a unei console KDE 


Pentru a putea realiza transferuri SOAP cu fişiere ataşate (SOAP with 
Attachments) va trebui să recurgem la modulul SOAP::MIME, care îmbunătăţeşte 
o serie de aspecte ale SOAP::Lite. Mai trebuie remarcat faptul că modulul 
SOAP.:Lite nu oferă suport pentru generarea automată de descrieri WSDL 
corespunzătoare serviciilor Web implementate. 

Pentru alte detalii privitoare la folosirea sesiunilor în cadrul serviciilor Web, 
a invocării unor servicii externe și a utilizării unor metode de autentificare în 
cadrul serviciilor Web dezvoltate, cititorii interesaţi pot consulta documentatiile 
si exemplele incluse în arhiva de instalare a modulului SOAP::Lize. 


1.5. Scrierea în Perl a clientului SOAP 


In acest moment putem scrie un client Perl simplu care să invoce metodele 

serviciului Web implementat. Vom realiza o interacțiune de bază cu utilizatorul, 

la nivelul liniei de comandă (prozzpr-ul interpretorului de comenzi, de obicei bash 

în Linux). Codul-sursă al programului-client e furnizat mai jos: 
#!/usr/bin/perl -w 


+ folosim modulul SOAP::Lite cu opțiunea de depanar 
use SOAP::Lite +debug => [qw(all)]; 


if (scalar(@ARGV) < 1) { 
print "Client de accesare a metodelor oferite de un 


serviciu Web\npentru accesarea sistemului de fisiere de p 
server.\n"; 
print "Sintaxa: $0 <fisier existent _pe_server>\n"; 
exit (1); 
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+ ne conectăm la server 
my $soap = SOAP::Lite 
->uri ('http://127.0.0.1:3333/XMLFiles/!) 
+ adresa spaţiului de nume 
-»proxy( 
'http://127.0.0.1:3333/XMLFiles/xml-files.pl'); 
+ locaţia serviciului 


împachetăm explicit parametrii, 

folosind nume calificate 

pentru parametrii metodei invocate 

my @params = (SOAP::Data-»name('filename', SARGV[0])); 


verificăm dacă fişierul există pe server 
Sresponse = $soap-»call('CheckIfExists' => @params); 


verificam dacă a apărut o eroare (SOAP fault) 

if (Sresponse->fault) | 

die 'A apărut o eroare: 
Sresponse->faultstring; 


1 


dacă rezultatul primit e nul, fişierul nu există 
if (!Sresponse->result) | 
die 'Fisier inaccesibil (nu există pe server?)'; 


invocăm metoda de redenumire a fişierului 
adăugând şi numele cel nou al acestuia 
push (@params, SOAP::Data->name('newname', 


SARGV[0] . '.renamed')); 


f afisám rezultatul executiei metodei 
print 'Redenumire realizatá cu ' 
$soap-»call('Rename' => @params) ->result; 


Programul va verifica existenţa unui fișier al cărui nume este furnizat de 
utilizator în linia de comandă, va încerca să-l redenumească (numele vechi va fi 
sufixat cu .renamed), apoi va afişa lista fişierelor existente pe server (putem 
verifica astfel dacă redenumirea s-a efectuat). 

În urma execuţiei acestui script, vom putea obţine un rezultat asemănător cu 
următorul (presupunem cá pe server există fișierul denumit portocak.tx?): 


(infoiasi)$ perl xml-files-client.pl portocale.txt 
Fisierul exista. 

Redenumire realizata cu succes. 
F 


isierel xistente pe server: 
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portocale.txt.renamed 
xml-files.pl 
xml-files.pl~ 


Prima cerere efectuata de programul-client este incapsulata intr-un mesaj 
HTTP de forma de mai jos, in care se pot observa cámpurile-antet HTTP, tipul 
continutului (fisier XML) si corpul mesajului SOAP (reprezinta invocarea metodei 
ChecklfExists cu parametrul corespunzător furnizat tot sub forma de marcaje 
XML): 

POST http://127.0.0.1:3333/XMLFiles/xml-files.pl HTTP/1.1 

Accept: text/xml 

Accept: multipart/* 

Accept: application/soap 

Content-Length: 517 


Content-Type: text/xml; charset-utf-8 
SOAPAction: 


"http://127.0.0.1:3333/XMLFiles/#CheckIfExists" 


<?xml version="1.0" encoding="UTF-8"?> 

<soap:Envelope 
xmlns:xsi-"http://www.w3.org/2001/XMLSchema-instance" 
xmlns : soapenc= 

"http: //schemas.xmlsoap.org/soap/encoding/" 

xmlns:xsde"http://www.w3.org/2001/XMLSchema" 

Soap:encodingStyle- 
"http://schemas.xmlsoap.org/soap/encoding/" 

xmlns:soap- 


"http://schemas.xmlsoap.org/soap/envelope/"» 
«soap: Body» 

«namespl:CheckIfExists 
xmlns:namespl-"http://127.0.0.1:3333/XMLFiles/"» 
«filename xsi:type="xsd:string"> 

portocale.txt 
</filename> 

«/namespl:CheckIfExists» 

</soap:Body> 
</soap:Envelope> 


Răspunsul oferit de server este: 


HTTP/1.1 200 OK 

Date: Fri, 04 Aug 2006 18:25:51 GMT 
Server: libwww-perl-daemon/1.36 
Content-Length: 523 

Content-Type: text/xml; charset=utf-8 
Client-Date: Fri, 04 Aug 2006 18:25:51 GMT 
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Client-Peer: 127.0.0.1 
Client-Response-Num: 1 
SOAPServer: SOAP::Lite 


<?xml version="1.0" en 
<soap:Envelope 


13333 
/Perl/0.65 5 


coding="UTF-8"?> 


xmlns:xsi-"http://www.w3.org/2001/XMLSchema-instance" 


xmlns:soapenc- 


"http://schemas.xmlsoap.org/soap/encoding/" 


xmlns:xsd="http://www.w3.org/2001/XMLSchema" 


soap:encodingStyle= 
"http://schemas.xm 


xmlns : soap= 
"http://schemas.xm 
<soap:Body> 
«namesp9:CheckIfExi 
xmlns:namesp9-"h 


«s-gensym27 xsi: 
«/namesp9:CheckIfEx 
«/soap:Body» 
</soap:Envelope> 


Se poate remarca faptul ca 


lsoap.org/soap/encoding/" 
lsoap.org/soap/envelope/"> 


stsResponse 
ttp://127.0.0.1:3333/XMLFiles/"> 
type="xsd:int">1</s-gensym27> 
istsResponse> 


valoarea răspunsului furnizat (întregul 1) este 


încapsulată în marcatorii XML din cadrul corpului plicului SOAP ce impacheteaza 
informaţiile vehiculate între serviciu și clienții săi. 


Lucrurile decurg similar pentru a doua cerere — corespunzătoare invocării 


metodei Rename — şi răspunsul 


aferent. 


Pentru a treia cerere, de invocare a metodei Lzs/, nu există argumente de 
intrare, în cadrul corpului plicului SOAP apărând doar: 


<namesp3:List xsi:nil="true" 


xmlns:namesp3="http 


://127.0.0.1:3333/XMLFiles/" /» 


Rezultatul metodei reprezintá o structurá XML de genul: 


«namesp4:ListResponse 


xmlns:namesp4-"http://127.0.0.1:3333/XMLFiles/"» 
«file name-"portocale.txt.renamed" /» 


«file name="xml-fil 


S.pl" 7» 


«/namesp4:ListResponse» 


Spatiile de nume de forma namespN sunt generate in mod automat de cátre 
SO.AP::Life pentru a indica apartenenţa fiecărui element XML din cadrul mesa- 


jului SOAP vehiculat. 
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In cazul in care clientul nu furnizează numele parametrului corect (de 
exemplu, în loc de filename se trimite file pentru metoda CheckIfExists), se va 
obţine un mesaj de tip fault SOAP emis de serviciu (codul entității emitente, șirul 
explicativ si adresa entității care a cauzat excepţia): 


<soap:Body> 
<soap:Fault> 
<faultcode> 
soap:Server.CheckIfExists 
</faultcode> 
<faultstring> 
Input parameter is missing 
</faultstring> 
<faultactor> 
http://127.0.0.1:3333/ 
</faultactor> 
</soap:Fault> 
</soap:Body> 


1.6. Invocarea serviciului de catre un client PHP 


Am dori ca serviciul să poată fi invocat de o aplicaţie Web, astfel încât 
interacțiunea cu utilizatorul să poată fi realizată prin intermediul unui browser 
Web. Aceasta o vom realiza scriind un client PHP, inter-operabilitatea având loc 
fără probleme, din moment ce mesajele sunt vehiculate via XML, indiferent de 
platformă. Programul PHP recurge la biblioteca N4SOAP (versiunea 0.6.5) si are 
următorul cod-sursă: 

<?php 

require once('lib/nusoap.php'); + utilizăm NuSOAP 


// instantierea unui client SOAP 

// pe baza descrierii serviciului Web 

Sclient = new soapclient ( 
'http://endirra.ro:3333/xml-files.pl'); 

// preluám posibilele erori 


Serr = Sclient->getError(); 
if (Serr) { 
// semnalám eroarea 
echo '<h3>Eroare de initializare</h3><pre>' 
Serr . '</pre>'; 


} 


// stabilim parametrii de intrare ai metodei invocate 
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Sparam = array('filename' => 'xml-files.pl'); 
+ există cu siguranță 
+ de încercat cu un fişier inexistent: 
+ Sparam = array('filename' => 'inexistent.xml'); 
// stabilim spatiul de nume folosit 
Snamespace = 'http://127.0.0.1:3333/XMLFiles/'; 


// realizăm apelul 
$result = Sclient->call('CheckIfExists', 
array('parameters' => Sparam), Snamespace, '', true); 
// verificám dacă există vreun fault 
if (Sclient->fault) 4 
echo '<h3>Fault</h3><pre>'; 
print_r($result); 
echo '</pre>'; 
) else { // verificăm dacă sunt erori 
Serr = Sclient->getError(); 
if (Serr) { 
echo '«h3»5Eroare«/h3»«pre»' . Serr . '</pre>'; 
) else { 
// afisám rezultatul 
echo '<h3>Rezultat</h3>'; 
echo '<p>Fisierul ' . (Sresult ? 


"există! : "e inaccesibil!) . '.</p>'; 


wa 


// cererea, răspunsul si informaţiile de depanar 
echo '<h3>Cerere</h3><pre>' 
htmlspecialchars ($client->request, ENT QUOT 
'«/pre»'; 
echo '«h3»Ráspuns«/h3»«pre»' 
htmlspecialchars (Șclient->response, 
'</pre>'; 
echo '<h3>Depanare</h3><pre>' 
htmlspecialchars($client-»debug str, ENT QUOTES) 
'</pre>'; 
?» 


[Ea] 
n 
— 


E 


NT QUOTES) 


După cum se poate remarca, se instantiazá un obiect Scent al clasei soapclient() 
pusă la dispoziţie de biblioteca mai sus menţionată. Constructorul necesită 
adresa Web a serviciului dorit a fi invocat. Posibilele erori survenite pot fi 
captate cu metoda gezError(), iar fau/t-urile SOAP via proprietatea fanit. 

În acest caz am invocat doar metoda de verificare a existenței unui fișier, 
recurgánd la metoda c4//(). Convenţia este ca parametrii transmisi să fie incapsulati 
într-un tablou (array). 
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Un posibil rezultat este ilustrat de figura 3, in care se remarca si afisarea 
cererii, a răspunsului si a informaţiilor privitoare la depanare, direct în programul 
de navigare Web. Programul-client PHP şi serverul SOAP scris în Perl au fost 
testate pe platformele Linux și Windows. Navigatorul Mozilla Firefox care 
realizează invocarea srpr-ului PHP rulează în Windows. 


@-93>-g80@82G84 | http: /endirra.rofsxml/xmbfiles-client. php v| © Go 


9€ Disable 53 CSS~ "à Foms g | File Edit View Bookmarks Tools Help 


Rezultat d meu rece (ae) å 


<< e > bp» £ » js-client2.php v 


Fisierul exista. 
Fisierele existente pe server 


Cerere , 

e document.txt renamed 
POST /xml-files.pl HTTP/1 e xml-files.pl 
Host: localhost:3333 . xml-files.pl- 


User-Agent: NuSOAP/0.7.2 
Content-Type: text/xml; charset-ISO-8859-1 
SOAPAction: "" 

Content-Length: 605 


<?xml version-"1.0" encoding-"ISO-8859-1"?-«SOAP-ENV:Envelope SOAP-ENY 


Raspuns 


HTTP/1.1 200 OK 

Date: Fri, 04 Aug 2006 18:53:20 GMT 
Server: libwww-perl-daemon/1.36 
Content-Length: 526 

Content-Type: text/xml; charset-utf-8 
SOAPServer: SOAP::Lite/Perl/0.65 5 


<?xml version-"1.0" encoding="UTF-8"?><soap:Envelope xmlns:xsi-"http:; 
Depanare 


2006-08-04 21:53:15.671876 soapclient: instantiate SOAP with endpoint 
2006-08-04 21:53:15.671979 soapclient: call: operation-CheckIfExists, 


Figura 3. Rezultatele execuției programelor PHP ce invocă metodele CheckIfExists 
şi List ale serviciului Web implementat in Perl 
(au fost folosite navigatoarele Mozilla Firefox si Opera) 


In cazul invocarii metodei Les, care întoarce drept rezultat un fragment de 
document XML, vom procesa datele obţinute prin intermediul extensiei Simple 
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XML (disponibila in PHP versiunea 5). Liniile de cod prezentand interes in acest 


context sunt următoarele: 


// realizăm apelul 
Sresult = Șclient->call('List', undefined, 
Snamespace, '', true); 
Serr = Sclient->getError(); 
if (Serr) { 
echo '«h3»5Eroare«/h3»«pre»' . Serr . '</pre>'; 
) else { 
// afisám lista de fisiere 
echo '<h3>Fisierel xistente pe server</h3><ul>'; 
// procesám ráspunsul SOAP via Simple XML 
$xml = simplexml load string ($client->responseData) ; 
foreach ($xml-»xpath("//file") as $file) | 
// afisám fiecare nume de fisier 
echo '«li»' . $file['name'] . '«/li»'; 


) 
echo '«/ul»'; 


Rezultatul obtinut este ilustrat tot de figura 3. 


2. Intet-operabilitatea intre diverse tehnologii, 
instrumente și limbaje de programare a serviciilor Web 


2.1. Dezvoltarea de servicii Web în .NET Framework 


În cadrul platformei .NET, un serviciu Web este considerat ca fiind un tip 
specific de assembly (formă atomică a unui modul de cod), tratat într-o manieră 
specială de către mediu. Serviciile Web sunt conţinute de fișiere cu extensia 
.asmx. Serverul Web Microsoft IIS (Internet Information Services) recunoaşte fişierele 
.asmx ca fiind servicii Web si în mod automat exportă funcţiile assembly-ului 
referentiat. 

Procesul de dezvoltare si exploatare a unui serviciu Web în .NET este 
(relativ) simplu: se scrie codul-sursa, se salveaza intr-un fisier .asmx, se exporta 
respectivul fișier într-un director virtual al serverului IIS si se invocă respectivul 
serviciu via un client. 
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Un serviciu Web simplu implementat in C# 


Să începem cu un serviciu Web extrem de simplu. Conform tradiţiei, primul 
program scris trebuie să fie unul care afișează „Salut, lume!” (,,He//o, world?’). 
Vom scrie un serviciu care să furnizeze mesajul „Bună IX", unde X reprezintă un 
şir de caractere introdus de utilizator (printr-un anumit client, desigur). Putem 
recurge la orice editor de texte favorit pentru a crea fișierul de cod C# cu 
numele salutari.asmx. 

Liniile programului nostru sunt următoarele: 


<%@ WebService Language="C#" Class-"Hello" %> 
using System.Web.Services; 


[WebService (Namespace="urn:Hello") ] 
public class Hello { 
[WebMethod] 
public string sayHello (string nume) { 
return "Buna " + nume; 


wa 


Linia <%@ WebService Language=” CH” Class "Hello" %> este o directivă care 
indică mediului .NET să exporte un serviciu Web, scris în limbajul C# si 
implementat de clasa cu numele He//. 

Linia using (in acest caz, using System.Web.Services) realizează includerea assembly-urilor 
necesare (în cazul nostru, a claselor privitoare la serviciile Web). 

Linia  /WebService(Namwespace= "urn:Hello")] este opţională, dar ne permite să 
specificăm diferite atribute ataşate serviciului Web dezvoltat. În acest caz, am 
stabilit un spaţiu de nume explicit (altfel .NET l-ar fi ales pe cel implicit, 
desemnat de hitp://tempuri.org/). 

[WebMethod] defineşte faptul că metoda clasei He// face parte din cadrul 
serviciului Web, fiind disponibilă posibililor clienți. De asemenea, pot fi 
specificate anumite proprietati legate de operaţiile pe care le realizează 
serviciul. 

După ce am creat un astfel de fișier, atunci când el este solicitat de un client 
via o cerere SOAP transportată prin HTTP, modulul .NET runtime va compila 
codul serviciului (daca nu a făcut-o deja), pentru a se putea invoca una dintre 
metodele dorite ale serviciului. 

În fapt, NET permite realizarea mai multor tipuri de cereri: 


— cereri privitoare la interfaţa serviciului (ceea ce oferă acesta), generându-se 
automat o descriere WSDL a acestuia; 
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— cereri care se interesează in mod explicit de o metodă furnizată de serviciul 
în cauză; 

— cereri de invocare a unei operaţii (metode) furnizate de serviciul Web (via 
SOAP 1.1 sau SOAP 2.0). 


Fisierul sa/utari.asmx va fi mutat în directorul public al serverului Web 
(pentru IIS, in mod implicit este ¢:\zmetpub\nmwroot\), iar invocarea se va 
realiza via URI-ul /zp:/ / localbost/ salutari.asmx (am presupus cá IIS rulează pe 
masina localá la portul 80). Un rezultat posibil e cel ilustrat de captura-ecran 
urmatoare: 


= 
©) Hello Web Service - Mozilla Firefox 


File Edit View Go Bookmarks Tools Help 


A-~@-~ @ €» cà F3 & | DL hitp:/Aocalhost/salutari.asmx v 


x Disable” la) Cookies” 5.5 CSS ©) Forms" 3^ Images” (9 Information [E] 


The following operations are supported. For a formal definition, 
please review the Service Description. 


* EEUU 


http: //localhost/salutari. asmx?op=sayHello 


Figura 4. Interfața Web de interactiune cu serviciul Web via 
programul de navigare 


Dând clic pe sayHello, vom putea parcurge o descriere detaliată privitoare la 
maniera de invocarea a metodei sayHe//o folosind cereri SOAP 1.1, SOAP 1.2 sau 
POST (vezi figura 5). 
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Ele Edit View Go Bookmarks Tools Help 


@-®- 3 3 €» c3 D3 d |] htp//localhost/salutari.asmx?op-sayHello mu m 
x Disable” la] Cookies” 5.) CSS” (©) Forms 3^ Images” (9 Information” [=] Miscellaneous” Z Outlines Resizer 
SOAP 1.1 SS 


The following is a sample SOAP 1.1 request and response. The placeholders shown need to be 
replaced with actual values. 


POST /salutari.asm« HTTP/1.1 

Host: localhost 

Content-Type: text/xml; charset-utf-8 
Content-Length: length 

S0aPAction: “arn: Hello/sayHello" 


<?xml version="1.0" encoding="ut£-s"?> 
Xsoap:Envelope xmlns:xsi="http: // wow. w?.org/2001/XMLSchema- instance" axmlns:xsd="http: // www.w?.or 
<soap: Body> 
XsayHello axmlns="urn:Hello"> 
<nume>string</nume> 
</ sayHello> 
</ soap: Body> 
</ soap: Envelope> 


HITP/ 1.1 200 0K 
Content-Type: text/xml; charset-utf-8 
Content-Length: length 


<?xml version-"l.0" encoding-"utf-9"?; 
<soap:Envelope xmlns:xsi-"http://www.w2.org/2001/XMLSchema-instance" xmlns:xsd-"http://www.w2.or 
<soap:Body> 
<sayHelloResponse «xmlns="urn:Hello"> 
<sayHelloResult>string</ sayHelloResult> 
</ sayHelloResponse> 
</ soap: Body> 
</ soap: Envelope> N 


SOAP 1.2 


The following is a sample SOAP 1.2 request and response. The placeholders shown need to be 
replaced with actual values. 


POST /salutari.aswa HTTP/1.1 

Host: localhost 

Content-Type: application/soaptxml; charset-utf-8 
Content-Length: length 


<?xml version-"l.0" encoding="ut£-5"2> 
Xsoapl2:Envelope xmlns:xsi="http: // wow.w2.org/2001/XMLSchema-instance" xmlns:xsd="http: / / wmo. w? . 
<soap12:Body> 
<sayHello xmlns="urn:Hello"> 
<nume>string</mume> 
</ sayHello> v 


Done 05 


Figura 5. Furnizarea informațiilor privitoare la forma cererii SOAP de invocare 
a metodei serviciului Web 


Pentru a testa funcţionalitatea serviciul Web creat, introducem un nume în 
formularul Web disponibil în cadrul paginii și apăsăm butonul Invoke. 
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File Edit View Go Bookmarks Tools Help 
@€-»- 804383 & E http://localhost/salutari.asmx?op=sayHello v 


«X Disable” [a] Cookies 5.5 CSS» 6) Formsy 3^? Images” (9 Information Miscellaneous 
—————————— 


sayHello 


Test 


To test the operation using the HTTP POST protocol, click the 'Invoke' button. 
Parameter Value 


nume: [Adria 


Land 
3 
x 
S 
x 
a 
|< 


Done OE Vv 


Figura 6. Invocarea metodei sayHello 


In urma rulării codului, vom obţine un rezultat precum cel din figura de mai 
jos (răspunsul întors este un document XML, asa cum era si de așteptat): 


<?xml versionz"1.0" encoding="utf-8" ?> 


«string xmlns="urn:Hello">Buna Adria</string> 


Figura 7. Rezultatul obtinut după execuția metodei invocate 


In cele ce urmează, vom implementa un client simplu care să invoce serviciul 
Web de mai sus din cadrul unui program C# interactiv. Fragmentul de cod care 


se ocupă cu invocarea propriu-zisă este următorul: 


using System; 

using System.Diagnostics; 

using System.Xml.Serialization; 
using System.Web.Services; 

using System.Web.Services.Protocols; 


namespace Salutari { 

[System.Web.Services.WebServiceBindingAttribute( 
Name-"HelloSoap", Namespace-"urn:Hello")] 

public class ClientSalut 
System.Web.Services.Protocols.SoapHttpClientProtocol 


— 


public ClientSalut () ( // constructor 
// stabilim adresa serviciului Web 
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this.Url="http://localhost/salutari.asmx"; 


[System.Web.Services.Protocols. 
SoapDocumentMethodAttribute ("urn:Hello/sayHello", 
RequestNamespace="urn:Hello", 


ResponseNamespace="urn:Hello", 
Use=System.Web.Services.Description. 


SoapBindingUse.Literal, 
ParameterStyle= 
System.Web.Services.Protocols. 


SoapParameterStyle.Wrapped) ] 
public string sayHello (string nume) { 
// vezultatul obtinut (tablou de obiecte) 
// in urma invocării metodei serviciului Web 


object[] rezult = 
this.Invoke ("sayHello", new object[]{nume}); 


// întoarcem primul element 
return ((string) (rezult [0])); 


Construcția [System Web. Services. WebS erviceBindingAtiribute...] stabileşte la com- 
pilare ca assembly-ul rezultat sa fie folosit pentru a invoca un serviciu Web. Cand 
acest assembly este compilat, .NET pune la dispozitie un mecanism intern 
facilitand functionarea cererilor SOAP. 

Linia System.Web. Services. Protocols.SoapH ttp ClientProtocol specifica protocolul care 
se doreşte a fi utilizat (în acest caz, SOAP peste HTTP). 

În cadrul clasei s-a mai creat un proxy pentru operaţia sayHello şi s-au 
specificat diferite atribute privitoare la serviciul Web invocat. Detalii sunt 
disponibile în cadrul documentatiilor ce însoțesc NET Framework. 

Programul-client recurge la Windows Forms şi la rulare, în cazul unei compilari 
cu succes, va afișa o fereastră în care se solicită utilizatorului să introducă un 
nume. În urma apăsării butonului Invoke, vom obţine un rezultat precum cel din 
figura 8. 

Cand a fost apăsat butonul Invoke, s-a produs un eveniment tratat într-o 
metodă implementată de client. În cadrul acestei metode se apelează sayHello din 
clasa proxy care invocă respectiva operaţie de pe server, returnindu-se rezultatul 
de mai sus. 
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15) x! 


Nume: [Reader 


EN x 


Buna Reader! 


ER 


Figura 8. Rezultatul invocárii serviciului Web 
dintr-un client interactiv 


Invocarea de servicii Web dezvoltate in CH de către clienți conceputi 
în alte limbaje de programare 


Ne propunem în continuare să demonstrăm inter-operabilitatea între serviciile 
Web create sub Windows — folosind mediul NET Framework — şi diversi clienti 
implementati in C#, Perl si PHP, ruland in Linux si/sau Windows. 

Pentru inceput vom dezvolta in C# un serviciu Web folosit pentru validarea, 
conform unei scheme XML, a documentelor XML existente pe server. 

Editarea codului-sursă și exploatarea serviciului se vor realiza prin intermediul 
aplicaţiei, disponibile gratuit, WebMarrix. Există două variante, una pentru 
versiunea 1.1 si cealaltă pentru 2.0. WebMatrix include si un miniserver Web, 
permiţând verificarea functionalitatii serviciilor dezvoltate. De asemenea, se 
poate utiliza Microsoft Visual Web Developer Express — mediu de dezvoltare dispo- 
nibil, de asemenea, gratuit (vezi figura 9). 

Serviciul va expune două metode: 


— Checkl {Exists — verifică existenţa documentului XML dorit a fi validat; 
— Validate — realizează validarea propriu-zisă. 
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New Web Site 


Templates: 


visual Studio installed templates 
2 8 2 € 
ASP.NET Web Pila] Personal Web Empty Web 
Site Service S Site Starter Kit Site 


My Templates 


"Atlas" Web Search Online 
Site Templates... 


A Web site For creating XML Web services 


Location: File System v| | e:\XMLVvalidate v 


Language: Visual C# v | 


Figura 9. Crearea unui serviciu Web via sablonul 
oferit de Microsoft Visual Web Developer Express 


Aceste metode sunt implementate in cadrul clasei purtand numele 
XMLValdator. Această soluţie de implementare a fost realizată pentru .NET 
Framework 1.1; în versiunea 2.0, în loc de XMLVahdatingReader (considerată demo- 
dată) se va recurge la XML Reader. Lăsăm cititorul să realizeze aceasta ca exerciţiu. 

<%@ WebService language="C#" class-"XMLValidator" %> 

using System; 

using System.Web.Services; 


using System.Xml; 
using System.Xml.Serialization; 


using System.Xml.Schema; 
using System.IO; 


// clasa care implementeazá serviciul Web 
[WebService (Namespace= 
"http://www.infoiasi.ro/XMLValidator") ] 
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public class XMLValidator { 


static private int validationMessages; 
static private string result; 


// folosim expl 
// pentru fieca 
[SoapRpcMethod] 


// metoda Web care verifică exist. 


[WebMethod] 
public bool Che 
return File.E 


} 


icit 
re metoda 


ckIfExists 


xists 


"SOAP RPC encoding', 


unui fisier 


(string filename) { 
(filename) ; 


// metoda Web de validare a unui fişier XML 


[SoapRpcMethod 
[WebMethod] 
public string V 


alidate 


(string filename) { 


// cititorul si validatorul de documente XML 


(tr); 


lidationType. Schema; 


a evenimentelor 


(ValidationHandler) ; 


doar citim documentul XML 


XmlTextReader tr = null; 
XmlValidatingReader vr = null; 
// initial, nici o eroare 
validationMessages = 0; 
result = ""; 
// încercăm să procesam documentul XML 
Ery 4 
// instantiem cititorul de conținut XML 
tr = new XmlTextReader (filename); 
// instantiem validatorul XML 
vr = new XmlValidatingReader 
// tipul implicit de validare 
// foloseşte XML Schema 
vr.ValidationType = Va 
// setám o metodá de semnalar 
// generate de validatorul XML 
vr.ValidationEventHandler += 
new ValidationEventHandler 
while ( vr.Read () ) 
; // nu facem nimic, 
) // final de "try" 
catch ( Exception e) { 
// returnám mesajul de exceptie 
return result 4 „Message; 
) 
finally | 
if ( tr != null ) 
tr.Close (); 
if ( vr != null ) 


vr.Close 


0; 


XML 
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// întoarcem succes sau numărul de erori 
return (validationMessages == 0 ? 
"valid" : "invalid ("+ 
validationMessages + ")"); 
} 
// metodă de tratare a erorilor de validare 
private static void ValidationHandler | 
object sender, ValidationEventArgs args) { 
result += args.Severity + 
"(" + args.Message + "). "; 
validationMessagestr; 


) 


Maniera de editare și compilare a codului C# este ilustrată in figura de mai jos. 


© sim! - Visual Web Developer 2005 Express Edition 
File Edit View Refactor Website Build Debug Tools Window Community Help 
e-U-dd *4aaio-c- 2-3) > oie 
Cj a, Na ae = La 45 
Service.asmx App_Code/Service.cs 


1$ XMLY alidator 


using System. Xml . Schema; 
using System. IO; 


10]d43 aseqeje d = 


a 


clasa utilizata pentru implementarea serviciului Web 


[WebService(Namespace-"http://127.0.0.1/XMLValidator/")] 


i [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfilel 1)] 
2i public class XMLValidator { 


se! 


Static private int validationMessages; 
static private string result; 


folosim explicit 'SOAP RPC encoding', pentru fiecare 
metoda 
[sdapRpenet hod] 
/|Specifies that SOAP messages sent to and from the method use RPC formatting | ZML 
([WebMethod] 
public bool CheckIfExists(string filename) mu 


3; 
20: 
21 

2 

7 


NNN [9 
10... 


/ metoda Web de validare a unui fisier XML 
Error List 
Q 1Enor | À 2Wfarmnings! i) 0 Messages 
Description File Line Col... Project 


» 2  'System.Xml.XmiValidatingPieader' is obsolete: 'Use Service.cs 36 Yi D:\sxml\, 
xmlReader created by XmlReader.Create[] method using 
appropriate XmlReaderSettings instead. 
http: //go.microsoft.com/fwlink /?linkid- 14202" 


Ready 


Figura 10. Construirea si depanarea codului serviciului Web in cadrul mediului de dezvoltare 
Microsoft Visual Web Developer Express 
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Mediul .NET pune la dispoziţie si o modalitate de generare a descrierii 
serviciului Web implementat, adică de accesare a reprezentării WSDL asociate. 
Astfel, putem inspecta comod — cu ajutorul unui instrument precum WSDL 
SOAP Analyser, integrat in deja cunoscutul editor oXygen, menţionat anterior în 
cadrul cărții de fata — informaţiile privitoare la metodele si signaturile acestora (a 


se vedea figura 11). 


NE WSDL SOAP Analyser 


WSDL 


Services XMLValidator 


Ports XMLY¥alidatorSoap 


Operations (Saas e v 


CheckIfExists 


Actions validate AS 


URL: http://localhost:8080/xml-validator.asmx 


SOAP Action | http://www.inFoiasi.ro/XMLValidator/ CheckIfExisks 


Request | Attachments | 


«SOAP-ENV:Envelope xmins:SO4P-EN\V="http:}schemas.xmlsoap, org/soap/envelope/"> 
<SOAP-ENV: Header! > 
<SOAP-ENV:Body > 
«CheckIfExists xmins="http:} www. infoiasi.ro/XMLYalidator"> 
«filename STRING </filename> 
xi CheckIfExists 
<{SOAP-ENV:Body > 
</SOAP-ENY:Envelope> 


Response 


<!-- Auto generated server sample response. --> 
<SOAP-ENY: Envelope :rmins:SOAP-ENV-"http:/Jschemas.xmlsoap.org/soap/envelope]" » 
<SOAP-ENY:Header} > 
<SOAP-ENY:Body> 
«CheckIfExistsResponse xmins="http://www. infoiasi.ro/XMLYalidator"> 
«CheckIfExistsResult BOOLEAN «/CheckIfExistsResult > 
</CheckIFExistsResponse > 
</SOAP-ENY:Body > 
</SOAP-ENY:Envelope> 


Figura 11. Objinerea informațiilor privitoare la metodele expuse 
de un serviciu Web 


Rularea serviciului Web implementat in .NET poate fi realizata atat in cadrul 
unui server Web precum IIS, cât și in serverul Web oferit de mediul de dezvoltare. 
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Alte exemple privind dezvoltarea de servicii Web sub platforma .NET sunt 
disponibile si în volumul lui Sabin Buraga (coord.), Situri Web la cheie. Soluţii 
profesionale de implementare, Polirom, Iasi, 2004. 


2.2. Un client C# pentru serviciul creat 


O implementare CH minimală a unui client disponibil în linie de comandă, 
având rolul de invocare a serviciului Web descris mai sus, este următoarea: 


using System; 
class XMLValidatorClient { 
public static void Main(string[] args) { 
if (args.Length == 0) { 
Console.WriteLine ("Sintaxa: 
xml-validator-client «document.xml»"); 


return; 
} 
try { 
Console.Write("Documentul '{0}' este... ", 
args[0]); 


// creăm o instanţă a clasei corespunzătoare 
// serviciului Web 
XMLValidator validator = new XMLValidator(); 


// invocám metoda de verificare a existenţei 
// fişierului la nivel de server 
if (validator.CheckIfExists(args[0])) { 
// există, deci putem realiza validarea 
string valid = validator.Validate(args[0]); 


// afişăm ceea ce a întors metoda invocată 
Console.WriteLine(valid + "."); 
} 
else 
Console.WriteLine ( 
"inaccesibil (nu există pe server?)."); 
} // final de 'try' 
catch (Exception e) { 
// a apárut o exceptie 
Console.WriteLine("\nExceptie: " + e.Message); 
return; 


} 


Numele fisierului XML dorit a fi validat este preluat de la linia de comanda, 
fiind regăsit in șirul de caractere args/0/. 
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Pentru ca programul să funcţioneze, va trebui generată o clasă intermediară 
(prox)), având rol de facilitare a dialogului dintre mașina locală și serverul pe care 
va fi rulat serviciul Web. Aceasta se realizează prin comanda următoare, având 
ca rezultat generarea unui fișier cu numele XMLVahdatorcs, pe baza descrierii 
WSDL a serviciul dezvoltat: 


"c:\Program Files\Microsoft.NET\SDK\vl.1\Bin\wsdl.exe" 
http://localhost:8080/xml-validator.asmx?WSDL 


Calea spre programul wsd/exe (pus la dispoziţie de .NET Framework) poate 
diferi, trebuind să fie ajustată în funcţie de situaţia concretă. Pentru versiunea 
„NET 2.0, se înlocuieşte „77.77 cu ,,v2.0”. În cazul nostru, am presupus că 
serviciul Web va putea fi invocat pe mașina /oca/bost, la portul 8080). 

Clientul C# ce validează documentul via serviciul Web de mai sus va trebui 
compilat printr-o linie de genul: 

c:\Windows\Microsoft.NET\Framework\vl.1.4322\csc /t:exe /r 


:System.Web.dll,System.XML.dll,System.Web.Services.dll 
XMLValidator.cs xml-validator-client.cs 


Interactiunea dintre un client si un server Web, via clasa proxy generatá, este 
prezentatá in figura 12. 


Client invocánd 
un serviciu Web 


Apel al metodei 2 
aserv. Web 


Serviciul Web 
implementat 


Implementare 
metoda 1 
Implementare 
metoda 2 
Implementare 
metoda N 


Implementare 
transfer asincron 


Figura 12. Interacțiunea dintre un client, clasa proxy si serviciul Web 
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Un posibil rezultat este ilustrat de captura-ecran urmatoare, in care se observa 
si descrierea WSDL generata automat de .NET Framework pentru serviciul Web 
dezvoltat. 


@€-®- & x) A LA & E http: /localhost:8080/xml-validator2. asmx 7w SDL ~| G 


2€ Disable” |a| Cookies" 5^ CSS- ©) Forms" 3^ Images” (9 Information Miscellaneous” 2 Dutlir 


— <wsdl: definitions targetNamespace="http://127.0.0. 1/X MIL Validator/"» 
<wsdl:types/> 
+ <wsdl:message name="ChecklfExistsS oapIn'"=</wsdl:message> 
+ <wsdl:message name="ChecklfExistsSoap Out"></wsdl:message> 
+ <wsdl:message name="ValidateSoapIn'></wsdl:message> 
+ <wsdl:message name="ValidateSoap Out"></wsdl:message> 
+ <wsdl:portType name="X MLV alidatorS oap"></wsdl:portType= 
— wsdl: binding name=" X MLValidatorSoap" type="tns X ML ValidatorSoap'7 
<soap: binding transport="http://schemas.xmlsoap. org/soap/http"/> 
+ <wsdl: operation name="ChecklfExists"></wsdl: operation? 
+ <wsdl: operation name="V alidate"></wsdl: operation? 
<hwsdl:binding> 
+ <wsdl:binding name=" XML alidatorS oap 12" 
type="tns X MLValidatorSoap" 7» €/wsdl: binding? 
— wsdl: service name-" XMLValidator"7 
— <wsdl:port name-"XMLValidatorSoap" binding-'tns X ML ValidatorSoap'7 
<soap:address location-"http //localhost:S0S0/zml-validator2. asmx"/ 


=hwsdl:port> cx C:\WINDOWS\system32\cmd.exe 
+ <wsdl:port name= 
"T e a. D:Xus.net?xml-validator-client.exe portocale.xml 
binding="tns: XMI Documentul 'portocale.xml' este... valid. 


<fwsdl:: ice> 
vee ore D:\ws.net> 


Figura 13. Raspunsul afisat de chentul care a invocat serviciul Web 


2.3. Accesarea dintr-un script Perl a serviciului Web 
implementat în .NET 


De asemenea, putem realiza un client conceput în limbajul Perl, apelând la 
modulul SOAP::Lite. Codul acestuia e similar celui descris mai sus, cu excepţia 
faptului că valoarea parametrului proxy a constructorului este o adresă de genul 
http:/ / winxp.infoiasi.ro:8080/ xml-validator.asmx, iat numele metodelor invocate sunt 
cele ale serviciului NET implementat. 
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Liniile care prezinta interes in contextul de fata sunt: 


+ ne conectăm la server 
my Ssoap = SOAP::Lite 
-»uri('http://127.0.0.1/XMLValidator/'"') 
# URI-ul spatiului de nume 
-»proxy( 
'http://127.0.0.1:8080/xml-validator2.asmx') 
# locatia serviciului 


-»on action(sub ( join('', 8) ]); 

my @params = (SOAP::Data-»name('filename', SARGV[0])); 
print "Documentul S$SARGV[0] este... "; 
# verificám daca fisierul XML existá pe server 
if (Ssoap->call("CheckIfExists" => @params)->result) | 

# ...Si invocám metoda de validare 

my Svalid = 

Ssoap->call("Validate" => @params) ->result; 
print $valid . ".\n"; 


} 
else { 
print "inaccesibil (nu există pe server?).\n"; 


e 


2.4. Invocarea din PHP a serviciului Web 


Similar, clientul PHP se bazează pe biblioteca NwSOAP si foloseşte descrierea 
WSDL a serviciului. Instantierea clientului SOAP în acest caz are forma: 


// instantierea clientului SOAP 
// pe baza descrierii serviciului Web 


Sclient = new soapclient ( 
"http://localhost:8080/xml-validator.asmx?WSDL', 
true); 


Dacă apelăm CheckI/Exists cu un nume de fișier inexistent, vom obţine mesaje 
similare celor din figura 14. 
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©) Mozilla Firefox 


File Edit View Go Bookmarks Tools Help 
@-®- e x) A um & Lj] http://localhost/sxml/client. php b Q 
| |_| http://localhost:8080...l-validator.asm«?wW'SDL | 


Rezultat 


false 
Cerere 


POST /xml-validator.asmx HTTP/1.0 

Host: localhost:8060 

User-Agent: NuSOAP/0.7.2 (1.94) 

Content-Type: text/xml; charset-ISO-8859-1 

SOAPAction: "http://www.infoiasi.ro/XMLValidator/CheckIfExists" 
Content-Length: 440 


<?xml version-"1.0" encoding-"ISO-8859-1"?-«S0AP-ENV:Envelope x 


Raspuns N 


HTTP/1.1 200 OK 

Server: Microsoft ASP.NET Web Matrix Server/0.6.0.0 
Date: Thu, 16 Feb 2006 14:52:21 GMT 
X-AspNet-Version: Z.0.50727 

Cache-Control: private, max-age=0 

Content-Type: text/xml; charset-utf-8 
Content-Length: 385 

Connection: Close 


Figura 14. Rezultatul obtinut la invocarea serviciului Web 
implementat in C# via un client PHP 


Folosind extensia SOAP inclusă in PHP 5, vom putea scrie următorul 
cod-sursa: 


$doc = $ REQUEST['xml']; 


try { 
Sclient = new SoapClient ( 
'http://127.0.0.1:8080/xml-validator2.asmx?WSDL', 
array('trace' => 1)); 


// $rez = $client-»CheckIfExists ($doc); 
$rez = S$Sclient-» call('CheckIfExists', 
array ($doc)); 
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echo 'Cererea efectuată:<br /><pre class="cod">' 
htmlspecialchars($client-»  getLastRequest(), 
ENT QUOTES) . '</pre>'; 
echo 'Ráspunsul obtinut:«br /><pre class="cod">' 
htmlspecialchars($client-»  getLastResponse(), 
ENT QUOTES) . '</pre>'; 
if (Srez == true) { 
Srez = $client-»Validate ($doc); 
echo "<p>Documentul $doc este $rez.</p>"; 
p] Else 1 
echo "«p»Documentul $doc e inaccesibil 


(nu existá pe server?)</p>"; 


} 
} catch (SOAPFault S$exception) { 
echo 'A apărut o excepție: ' 
Sexception->faultstring; 


Numele documentului dorit a fi validat poate fi furnizat prin GET in sirul de 
interogare. In invocarea serviciului Web ne folosim de fisierul WSDL asociat 
acestuia. Astfel, o metodă poate fi apelata direct, ca metodă a obiectului Schent, 
instanță a clasei SoapChent. După cum am văzut anterior, o apelare de „nivel 
scăzut” se poate efectua via metoda __cal/(). În exemplul de fata am afişat si 
cererea și răspunsul SOAP, așa cum se remarcă în figura următoare. 
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| Un client SOAP - Opera 
File Edit View Bookmarks Tools Help 


er ——— me 


44 €e > b» ^ |] ient.php?xml=projects-xsd2.xml + 69 
Cererea efectuata: 


<?xml version-"1.0" encoding="UTF-8"?> «SOAP-ENV:Envelope 
xmlns:SOAP-ENV-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:nsi-"http://127.0.0.1/XMLValidator/" xmlns:xsd-"http:// 
www.wuw3.org/2001/XMLSchema" xmlns:xsi="http://uww.w3.org/2001/ 
XMLSchema-instance" xmlns:SOAP-ENC-"http:// 
schemas.xmlsoap.org/soap/encoding/" SOAP- 
ENV:encodingStyle-"http://schemas.xmlsoap.org/soap/encoding/ 
"><SOLP-ENV: Body><ns1:CheckIfExists><filename 
xsi:type="xsd:istring">projects-xsdz2.xml</filename></ 
nsi:CheckIfExists»c/SOAP-ENV:Body-c/SOAP-ENV:Envelope- 


Raspunsul obtinut: 


<?xml version-"1.0" encoding="uttf-8"?><soap: Envelope 
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:tns-"http://127.0.0.1/XMLValidator/" 
xmlns:types-"http://127.0.0.1/XMLValidator/encodedTypes" 
xmlns:xsi-"http://www.w3.org/2001/XMLSchema-instance" 
xmlns:xsd-"http://www.w3.org/2001/XMLSchema"»csoap:Body 
soap:encodingStyle-"http://schemas.xmlsoap.org/soap/encoding/ 
"><tns:CheckI£fExistsResponse><CheckIfExistsResult 
xsi:type="xsd:boolean">false</CheckI£ExistsResult></ 
tns:CheckI£ExistsResponse></ soap: Body></ soap: Enve lope> 


Documentul projects-xsd2.xml e inaccesibil (nu exista pe server?) N 


Figura 15. Rezw/tatul obținut la invocarea serviciului Web 
via un client ce recurge la extensia Soap din PHP 5 


2.5. Invocarea de servicii Web externe 


Daca pana in momentul de fata am scris diversi clienti care invocau metode ale 
unor servicii Web proprii, e timpul sa descriem modalitatea de a obţine rezultate 
din partea unor servicii Web externe, dezvoltate de terţe organizaţii. Nu vom mai 
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avea acces la codul-sursă al implementării, ci doar la interfaţa serviciului — oferită 
de documentul WSDL ce-l descrie. 


WSDL SOAP Analyser 


WSDL 


Services XMethodsQuery 


Ports *MethodsQuerySoap 


[0/4 4- «I get allServiceNames 


Actions 


URL: http://www.xmethods.net/interFaces/query 


SOAP Action 


Request | Attachments | 


«SOAP-ENV:Envelope :rmins:SOAP-ENV-"http:/schemas.xmlsoap.org/soap/envelope/" > 
«SOAP-ENV:Header] > 
xSOAP-ENV:Body > 
<oxy:getallServiceNames :mlns:oxy-" http: www.xmethods.net/interfaces/query" 
SOAP-ENV:encodingStyle-"http://schemas.xmlsoap.org/soap/encoding/"] > 
</SOAP-ENY: Body > 
</SOAP-ENY: Envelope > 


Response 


«1-- Auto generated server sample response. --> 

<SOAP-ENY: Envelope xmlns:SOAP-ENV-"http:I/schemas.xmlsoap.org/soap/envelope/" > 
<SOAP-ENY: Header} > 
<SOAP-ENV: Body > 

<oxy:getallServiceNames xmins:oxy="http://www.xmethods.netjinterfaces/query" 
SOAP-ENV:encodingStyle-"http:/schemas.xmlsoap.org/soap/encoding/"] > 

</SOAP-ENY: Body > 

</SOAP-ENY: Envelope > 


Figura 16. Consultarea metodei getAllSetviceNames() 
a serviciului de interogare disponibil pe situl XMethbods 
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„Accesarea serviciului de interogare oferit de XMethods 


Unul dintre siturile care pun la dispoziţie diverse servicii Web publice este 
XMethods — www.xmethods.net. Pentru a accesa lista serviciilor Web oferite, vom 
invoca prin SOAP una dintre metodele serviciului Web de interogare oferit de 
organizația XMe/hods. Consultând documentul WSDL de la adresa ///p:// 
www.xmethods.net/interfaces/query.wsdl, observăm ca putem folosi metoda 
getAllServicesName(), care furnizează numele si identificatorii universali unici ai 
tuturor serviciilor Web înregistrate. Recurgând la instrumentul WSDL SOAP 
Analyser deja amintit în cadrul lucrării de față, obținem informațiile din figura 16. 

Clientul care apelează această metodă este scris în limbajul Perl si are 
următorul cod-sursă (firesc, utilizăm modulul SOAP::Lite): 


use SOAP::Lite; 
@params = ( ); + nu există parametri de intrare 


+ apelăm metoda serviciului Web 

Sresponse = SOAP::Lite 
-»proxy("http://www.xmethods.net/interfaces/query") 
-»uri("http://www.xmethods.net/interfaces/query") 
-»call('getAllServiceNames' => @params) ; 


+ semnalăm erorile SOAP, dacă există 
die "Fault: " . Sresponse->faultcode 
" " , Sresponse->faultdetail . " " 
Sresponse->faultstring 
if Sresponse->faultcode; 


+ afişăm o parte dintre serviciile Web întoarse 


foreach $r (Sresponse->dataof ('//name')) | 
if ($r->value =~ /^Co/) ( + numele începe cu 'Co' 
print $r-»value . "n"; 


} 

Cererea va avea următoarea formă: 

POST http://www.xmethods.net/interfaces/query HTTP/1.1 

Accept: text/xml 

Accept: multipart/* 

Accept: application/soap 

Content-Length: 453 

Content-Type: text/xml; charset-utf-8 

SOAPAction: "http://www.xmethods.net/interfaces/ 
query#getAllServiceNames" 
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<?xml version="1.0" encoding="UTF-8"?> 
<soap:Envelope 
xmlns:xsi-"http://www.w3.org/2001/XMLSchema-instance" 
xmlns:soapenc- 
"http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
soap:encodingStyle= 
"http://schemas.xmlsoap.org/soap/encoding/" 
xmlns : soap= 
"http://schemas.xmlsoap.org/soap/envelope/"> 
<soap:Body> 
<getAllServiceNames 
xmlns-"http://www.xmethods.net/interfaces/query" 
xsi:nil-"true" /» 
«/soap:Body» 
</soap:Envelope> 


Serverul va întoarce un mesaj precum următorul (observati codificarea SOAP 
a răspunsului): 


HTTP/1.1 200 OK 
Connection: close 
Date: Sat, 12 Aug 2006 09:41:16 GMT 
Server: Apache/1.3.26 (Unix) Enhydra-Director/3 
PHP/4.0.6 DAV/1.0.3 AuthNuSphere/1.0.0 
Content-Length: 43538 
Content-Type: text/xml; charset=UTF-8 
Servlet-Engine: Enhydra Application Server/3.1.1bl 
(JSP 1.1; Servlet 2.2; Java 1.4.2 03; 
Linux 2.4.7-10smp 1386; 
java.vendor-Sun Microsystems Inc.) 


<?xml version='1.0' encoding='UTF-8'?> 

<soap:Envelope 
xmlns:xsi-'http://www.w3.org/2001/XMLSchema-instance' 
xmlns:xsd-'http://www.w3.org/2001/XMLSchema' 
xmlns : soap= 


http: //schemas.xmlsoap.org/soap/envelope/! 
xmlns:soapenc= 
h 
I 


ttp://schemas.xmlsoap.org/soap/encoding/' 
ns:n4= 


http://www.xmethods.net/interfaces/query.xsd'> 
<soap:Body soap:encodingStyle- 
'http://schemas.xmlsoap.org/soap/encoding/' 
xmlns : soap= 
'http://schemas.xmlsoap.org/soap/envelope/'» 
«n:getAllServiceNamesRespons 
xmilns:n="http://www.xmethods.net/interfaces/query'> 
<Result soapenc:arrayType-'n4:IDNamePair[476]'» 
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<i> 
«id»uuid:F73777F6-1113-7D28-BE46-2A5E2B8C0313«/id» 
<name>Weather by City</name> 
</i> 
<!-- încă 475 de intrări --> 
</Result> 
</n:getAllServiceNamesResponse> 
</soap:Body> 
</soap:Envelope> 


Se returnează un document XML conţinând codificarea unui tablou de 
perechi (24, name) pentru fiecare serviciu disponibil. Deoarece sunt foarte multe 
intrări, programul nostru nu va afișa decât numele serviciilor care încep cu 
caracterele „Co”. Rezultatul rulării este ilustrat în continuare: 


(infoiasi)$ perl servicii-xmethods.pl 
Country Information WebService 
Conversions 

CountCheat Countdown Service 

Congress Member Directory 

Code39 Bar Code 

ColdFusion Tip-of-the-Day 


CountryWebservice 


Pentru a obtine informatii referitoare la un anumit serviciu, vom putea 
recurge la metoda getServiceDetail(), care are ca parametru de intrare identi- 
ficatorul serviciului respectiv și care furnizează un răspuns având structura din 
figura 17. 

Implementarea programului care apelează getServiceDetail() folosind Perl sau 
oricare alt limbaj de programare (lucrurile decurg similar cu cele menţionate mai 
sus) o lăsăm ca exerciţiu pentru cititor. 
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[_] ServiceDetail mhe) 


shortDescription 
implementationID 


wsdlURL 
inFoURL 
discussionURL 


publisherID 


Figura 17. Structura arborelui corespunzător documentului XML privitor la informaţiile 
despre un serviciu Web oferit de XMetbods 


Invocarea serviciilor puse la dispozitie de Google 


Motorul de cáutare Google pune la dispozitie o serie de servicii Web care pot fi 
utilizate in cadrul aplicatiilor noastre via SOAP. Vom exemplifica mai jos cum 
se poate folosi un serviciu de căutare si unul de verificare gramaticală (spe// 
checking) dintr-o aplicaţie scrisă în Visual Basic .NET (adaptare după tutorialele 
disponibile pe Web). 

Primul pas este cel de creare a unui cont la Google și obținerea unei chei cu 
ajutorul căreia se pot realiza maxim o mie de interogări pe zi — detalii la /7p:// 
www.google.com / apis/ . 

Următoarea etapă presupune crearea unui proiect de tip Windows Application 
în cadrul mediului de dezvoltare Visual Studio .NET. Vom adăuga o referință la 
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serviciul oferit de Google, astfel încât să avem acces la acesta (vezi figura 18, in 
care se pot remarca și metodele ce pot fi folosite). 


Add Web Reference 


Navigate to a web service URL and click Add Reference to add all the available services. 


Q Back e | Bl Ai 


URL: | http://api.google.com/GoogleSearch. wsdl v Ej Go 


| Web services found at this URL: 


"GoogleSearchService" Description mea 


- GoogleSearch 


Methods 
= doGetCachedPage ( ) 
= doGoogleSearch ( ) 
a doSpellingSuggestion ( ) 


Web reference name: 


com.google.api 


Figura 18. Addugarea unei referințe Web spre serviciul Google 
(se foloseste un document WSDL indicat de un URI) 


După introducerea URI-ului ///p:/ / api.google.com/ 
GoogleSearch.wsdl, apăsaţi butonul Add Reference, care 
determina adaugarea acestei referinte Web la proiec- 


Solution Explorer 
a ae 


s googleapi 


i tul nostru. În fereastra Solution Explorer, referința va 
Sa) My Project 


fi redenumită drept Google; a se urmări figura ală- 


=) gy Web References 


e: turata. 


23 app.config Vom crea o interfaţă care va solicita de la uti- 


ES] Form1.vb lizator un text folosit ca expresie de cautare, serviciul 


Google returnand numărul de rezultate (pagini Web) 
găsite. De asemenea, utilizatorul va putea introduce un șir de caractere scris în 
limba engleză, iar Google — via metoda doSpellingS uggestion() — va furniza termenul 
corect în urma realizării operației de spel checking. 

Invocarea primei metode — adică doGoogleSearch() — va avea loc la apăsarea 
butonului etichetat Nr pag. găsite, conform codului de mai jos: 


DEZVOLTAREA SI UTILIZAREA SERVICIILOR WEB 223 


Private Sub btn Search Click ( 
ByVal sender As System.Object, 
ByVal e As System.EventArgs) Handles NrPag.Click 
' Cheia de licentiere obținută de la Google 
Dim MyLicenseKey As String 


' 


Instantierea serviciului de căutare 

Dim MyService As Google.GoogleSearchService = New 
Google.GoogleSearchService() 

Rezultatul obtinut in urma invocárii 

Dim MyResult As Google.GoogleSearchResult 
MyLicenseKey = "mT2Mpq9O0FHLchbCY2F6WYAvEY39I7mDO" 
' Invocám metoda 

MyResult = MyService.doGoogleSearch (MyLicenseKey, 


ExpresiaCautata.Text, 0, 1, False, "", _ 
Bal SE Ww, Mi NN) 
' Obtinem nr. de rezultate 
NrRez.Text - "Numarul de rezultate gásite este:" & 
CStr(MyResult.estimatedTotalResultsCount) 
End Sub 


Liniile responsabile cu apelarea celei de-a doua metode la apăsarea butonului 
Spell checking sunt următoarele: 


Private Sub btn SpellChecking Click ( 
ByVal sender As System.Object, 
ByVal e As System.EventArgs) Handles Spelling.Click 
Dim MyLicenseKey As String 
Dim MyService As Google.GoogleSearchService - New 
Google.GoogleSearchService() 
Dim MyResult As String 
MyLicenseKey = "mT2Mpq9O0FHLchbCY2F6WYAvEY39I7mDO" 
MyResult = MyService.doSpellingSuggestion 
(MyLicenseKey, TextulDeVerificat.Text) 
TextCorect.Text - "Google afirmá cá e corect: " & 
MyResult 
End Sub 


Un rezultat posibil e ilustrat de figura 19, in care se pot observa atat 
rezultatele obţinute printr-o interogare manuală a motorului Google, cát si cele 
întoarse de serviciul Web pus la dispoziţie. 
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Web Imagini Grupuri Director 


x | Căutare avansată 
Go ogle metaresurse Caută E 


Caută: e in WWW ©) pagini scrise în limba română _ pagini din România 


Web 


intrebare.ro Portal pentru cei ce gindesc si au intrebari! 

.. metode si aplicatii , Ed . Albastra , Cluj - Napoca , 2000 [ 4 ] Metaresurse in sisteme 
distribuite - Referat Doctorat , Alboaie Lenuta , mai 2004 ; ... 
www.linkuri.ro/cgi-bin/cauta.cgi?cs-UTF- 

8&q-jocuri*cu*masini&ch-http:962F %2Fwww.intrebare.ro%2Fart... - 44k - Rezultat 
suplimentar - In Cache - Pagini similare 


EE) Google API 
O imagine asupra sistemlor distril 
[3]Florian Mircea Boian, Programarea dig 
Cluj-Napoca.2000 [4]Metaresurse in sis 


www.intrebare.ro/articole sd.html - 39k metaresurse Numara pag. gasite 


Numarul de rezultate gasite este: 2 


brainnnnstarming Spell checking 


Google afirma ca e corect: 
‘brainstorming’ 


Figura 19. Rezw/tatele obtinute via serviciul Web oferit de Google 


Observăm, așadar, cu câtă ușurință se pot încorpora serviciile Web oferite de 
Google (precum cel de căutare sau cel privitor la informaţii topografice — via 
Google Maps), în aplicaţiile noastre. Utilitatea acestora poate fi foarte mare în 
crearea de aplicaţii informative sau de divertisment, care pot utiliza diverse 
resurse disponibile pe Web. De asemenea, serviciul de spe// checking se poate 
integra în cadrul altor programe sau aplicaţii Web. Alte utilizări sunt cele 
privitoare la implementarea unor modalități de căutare pe Web din linia de 
comandă sau widget-uri grafice, ori realizarea de statistici privind informaţiile 
despre un anumit subiect de-a lungul timpului. 


2.6. Folosirea instrumentului gSOAP pentru C/C++ 


Suita de unelte gSOAP are drept scop simplificarea dezvoltării de servicii Web 
prin SOAP si de implementare de clienti pentru invocarea acestora în limbajele 
C şi C++. Se pune la dispoziţie un compilator cu rolul de generare a codului-sursă 
C/C++, pe baza unui fişier antet. De asemenea, avem la dispoziţie și o bibliotecă 
de clase, plus diverse rutine menite să codifice tipurile de date native C++ în 
XML. Suplimentar, gSOAP furnizează si un mecanism de garbage collection. Modelul 
de dezvoltare a serviciilor Web adoptat de gSOAP este cel clasic, bazat pe 
paradigma RPC. 
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Argumentul ca gSOAP este un instrument matur este dat de faptul ca IBM 
foloseste gSOAP pentru dezvoltarea de servicii Web destinate dispozitivelor 
mobile (probabil, datorită necesităţii de utilizare minimă a memoriei si a unei 
viteze mari de procesare), iar proiectul european GridLab l-a adoptat pentru 
construirea de servicii destinate sistemelor de tip grid (detalii si în capitolul 7). În 
acest moment, gSOAP este dezvoltat în cadrul Source Forge, pornindu-se de la 
versiunea inițială oferită de Universitatea din Florida. 

Documentatiile necesare și o suită de exemple sunt disponibile în cadrul 
distribuţiei open source a pachetului gSOAP. 

Vom detalia, ca exemplificare, maniera de dezvoltare a unui serviciu Web 
care, primind un număr, va verifica dacă acesta este prim. Vom crea trei fişiere: 


— nrprim.b, fişier antet cu informaţii privind funcţiile RPC ce urmează a fi 
invocate; 

— unrprimserver.e, reprezentând codul serverului; 

— nnprimclient.c, reprezentând programul client. 


Ca si în situaţiile de mai sus, vom asocia un spaţiu de nume XML serviciului 
Web dezvoltat. În fişierul antet se va face corespondenţa între spaţiul de nume 
stabilit și prototipurile fiecăreia dintre funcțiile serviciului Web implementat. 
Codul acestui fișier antet este următorul: 

//numele serviciului: nrprim 

//stilul de vehiculare a mesajelor: rpc 

//spatiul de nume: http://localhost/nrprim.wsdl 

//URI-ul serviciului: http://localhost/nrprimserver.cgi 


/* funcţia oferită de serviciul Web */ 
int ns nrprim (double numar, double *rezultat); 


In cazul gSOAP, se foloseşte convenţia următoare: toti parametrii funcțiilor 
sunt considerați parametri de intrare, cu excepţia ultimului (care va conţine 
rezultatul). De asemenea, valoarea întoarsă este întotdeauna zn/, putând fi folosită 
pentru diagnosticarea eventualelor erori survenite. 

Furnizăm mai jos codul C al serverului: 


include "soapH.h" 
include "nrprim.nsmap" 


int main(int argc, char **argv) { 
int m, s; /* descriptori de socket */ 
struct soap soap; /* include mesajele SOAP */ 
soap init(&soap); /* initializám... */ 
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if (argc < 2) /* oferim servicii ca un CGI */ 
soap serve(&soap); 
else { 
/* atagám serverul la un port 
specificat in linia de comandá (argv[1]) */ 
m = soap bind(&soap, NULL, atoi(argv[1]), 100); 
if (m < 0) { 
/* afisám eroarea survenitá */ 
soap print fault(&soap, stderr); 
exit(-1); 
} 
fprintf(stderr, "Conexiune reusitda.\n"); 
while (1) { 
// acceptăm cereri din partea clienţilor 
S = soap accept (&soap); 
if (s < 0) { /* a intervenit o eroare */ 
soap print fault(&soap, stderr); 
exit(-1); 
} 
fprintf(stderr, "S-a conectat un client.\n"); 
soap serve(&soap); /* deservim clientul... */ 
soap end(&soap); /* am terminat */ 


} 


return 0; 


/* funcţia invocată la apariţia cererii 
din partea unui client */ 

int ns nrprim (struct soap *soap, 
double numar, double *rezultat) { 


int contor - 2; 
int temp = (int) numar; 
while (contor « temp) { /* verif. dacă e prim */ 
if (temp $ contor !- 0) 
contortt; 
else { 
*rezultat = 0; 
break; 
} 
} 
if (contor == temp) 
*rezultat = 1; 


return SOAP OK; 
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Mai trebuie sa descriem codul-sursa al clientului: 


#include "soapH.h" 
#include "nrprim.nsmap" 


/* URI-ul serviciului */ 
const char server[] = 
"http://127.0.0.1/cgi-bin/nrprimserver.cgi"; 


int main(int argc, char **argv) { 
struct soap soap; 


double numar; /* numărul solicitat */ 

double rezultat; /* rezultatul primit */ 

if (arge < 2) { 
fprintf(stderr, "Introduceţi un număr. n"); 
exit (0); 

) 

soap init(&soap); /* initializare... */ 

numar = atoi(argv[1l]); 


/* invocám funcţia via SOAP */ 
soap call ns nrprim (&soap, server, "" 
numar, &rezultat); 
/* verificám dacá au apárut erori */ 
if (soap.error) { 
Soap print fault (&soap, stderr); 
exit(1); 
} 
else { 
if (rezultat == 0) 
printf("Ati dat un număr care nu este prim\n"); 
else 
printf("Ati dat un număr prim\n"); 


} 

/* finalizăm dialogul cu serverul */ 
soap destroy(&soap); 

Soap end(&soap); 

soap done(&soap); 

return 0; 


eu 


Pentru a facilita compilarea diferitelor servicii Web, distribuţia gSOAP pune la 
dispoziţie un fişier Makefile pe care puteţi să-l ajustati dupa dorinţă. În fişierul 
Makefile folosit de noi, se apelează compilatorul gSOAP RPC, numit soapepp2, in 
maniera următoare (opţiunea — este folosită pentru a se obține diversele 
fisiere-sursa necesare): 


| (infoiasi)$ ./soapcpp2 -c nrprim.h 
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Similar manierei de dezvoltare a aplicatiilor RPC clasice, vor rezulta o serie 
de fișiere: soapStub.h, soapH.h, soapC.c, soapChent.c, soapServerc etc. 

În acest moment, codul va fi compilat si legat folosindu-se sfdsoap2.c (respectiv, 
stdsoap2.cpp pentru C++ în loc de C). Eventual, executabilul rezultat va putea fi 
apoi instalat ca un script CGI. 

Să urmărim in figura de mai Jos testarea funcţionării serviciului: 


= —P Seushell| Nom E KONSOTE pa 


Session Edit View Bookmarks Settings Help 
A)| Shell No. 2 | ill Shell No. 4 | Shell | a Shell No. 6 


root@adria: /var/www/cgi-bin# pwd 
/var/www/cgi-bin 
root@adria: /var/www/cgi-bin# ls -al 


total 428 

drwxr-xr-x 2 root root 4096 2006-03-06 11:14 ./ 

drwxr-xr-x 5 root root 4096 2001-02-26 03:59 ../ 

-rwxr-xr-x 1 root root 131452 2006-03-06 10:32 nrprimclient* 
-rwxr-xr-x 1 root root 131485 2006-03-06 16:32 nrprimserver* 
-rwxr-xr-x 1 root root 131485 2006-03-06 10:33 nrprimserver.cgi* 
-rw-r--r-- 1 root root 268 2004-10-31 23:00 printenv 
-rwxr-xr-x 1 root root 757 2004-10-31 23:00 test-cgi* 
-IwX--X--X 1 root root 757 2006-02-27 20:25 test.cgi* 


root@adria: /var/www/cgi-bin# ./nrprimclient 10 
Ati dat un numar care nu este prim 

root@adria: / var /www/cgi -binit ./nrprimclient 29 
Ati dat un numar prim 

root@adria: /var/www/cgi-bin# [] 


Figura 20. Rularea programului-chent dezvoltat cu gSOAP 


2.7. Implementarea serviciilor Web in Java 


Instrumentul Apache Axis2 


Apache Axis isi are originea in Apache SOAP, prima soluţie, bazată pe SOAP 1.1, 
oferită de fundaţia Apache pentru conceperea de servicii Web. Limbajele de 
programare care pot fi folosite sunt C++ și Java. 

Cel mai recent efort, numit Axis2, reproiectează arhitectura Axis/Java si 
Axis/C++, procesarea realizându-se în stilul s/a/e/ess (aceasta permite codului să 
fie rulat în paralel, de fire de execuţie separate). De asemenea, se oferă și un 
model informational (information model, persistent, sistemul putând fi repornit 
fără pierderi de date. Arhitectura interna a Apache Axis? este una modulară, 
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constand din diverse componente, precum modulul de procesare XML (bazat pe 
„Apache Xerces), procesorul de mesaje SOAP, modulul de exploatare a serviciilor 
(deployment), generatorul de documente WSDL, interfaţa de programare a clienților 
SOAP și modulul de transport al datelor. 

Suplimentar, Apache Axis2 permite includerea de servicii Web „din zbor”, 
astfel încât servicii Web noi să poată fi rulate fără întreruperea execuţiei 
sistemului. De asemenea, se pot realiza actualizări (modificări) ale unui serviciu 
deja existent, fără a opri sistemul (desigur, eventualele schimbări produse pot 
conduce la pierderea de informaţii). 

Pentru a putea scrie o aplicaţie în Java folosind Ax7s2 aveţi nevoie de 
următoarele componente software: 


— Apache Geronimo — exemplele furnizate mai jos au fost rulate pe acest server, 
pe baza căruia este construit si IBM WebSphere Community Edition. Desigur, 
puteţi recurge si la un alt server. Pentru a prelua Geronimo, vizitaţi adresa 
http:/ | geronimo.apache.org/downloads.html. 

— Apache Axis2 (oti o altă implementare SOAP). Instrumentele puse la dispoziție 
reduc timpul de dezvoltare a codului. Puteţi obține Apache Axis2 de la adresa 
http:/ [ ws.apache.org/ axis2/ download.cgi (remarcăm faptul că distribuţia .war este 
folosită pentru dezvoltarea de servicii Web, iar cea binară vă ajută la crearea 
clienților); 

— Java 2 Standard Edition începând cu versiunea 1.4. 


Pornind de la premisa că uneori instalarea diferitelor instrumente „costă” mai 
mult timp decât dezvoltarea propriu-zisă a aplicației (deși nu este cazul aici), 
vom prezenta în continuare pașii necesari realizării unui serviciu Web în Java, 
folosind componentele software enumerate mai sus. 

După ce ati transferat Geronimo, trebuie doar să dezarhivati serverul în oricare 
director doriți (pentru prevenirea eventualelor probleme, evitati instalarea — in 
cazul Windows — în directoarele Program Files sau Documents and Settings). Pentru 
exemplele următoare, presupunem serverul Geronimo stocat in directorul 
c:\ geronimo. 

Puteţi apoi porni serverul, fie din linia de comandă, fie ruland fişierul 
startup.bat. În primul caz, introduceţi de la prompt-ul sistemului liniile: 


cd \geronimo\bin 
java -jar server.jar 


Testati rularea serverului, introducând adresa ///:/ /localhost:8080 în browser-ul 
preferat. In caz de succes, veţi obţine informaţiile din figura de mai jos. 
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APACHE 
LII GERONIMO 
Welcome! 
Apache Tomcat/5.5.15 


If you're seeing this page via a web browser, it means you've setup 
Apache Geronimo™ successfully. Congratulations! 


FAQ As you may have guessed by now, this is the default home page for Geronimo. If you're seeing this 
Wiki page, and you don't think you should be, then either you're either a user who has arrived at new 
Geronimo Documentation installation of Geronimo, or you're an administrator who hasn't got his/her setup quite right. If you 
Additional Documentation need help setting up or administering Geronimo, see the Geronimo Documentation. 


If you'd like to get started configuring Geronimo and the applications and services available in 
Geronimo, you might want to start with the Geronimo Admin Console (if this is your first time using 
Geronimo, the admin username is probably "system" with password "manager", though if you used 
the installer you got to choose your own during the installation). 


The Geronimo Home Page 
Problem Tracking Database 
Users Mailing List Archive 
Developers Mailing List Archive 
Geronimo IRC chat 


Would you like your application to appear at this URL? 

To set the context root for a web application, you can write a Geronimo 
deployment plan that uses the context-root element to specify the URL prefix 
used to reach that application. If you specify a context root of "/" then the 
application will appear at this URL. However, you'll need to stop this small 
Welcome application first! 


Your web deployment plan should look like this, and you can either pack it into 
Servlet Examples Exam les the WAR at WEB-INF/geronimo-web xml or provide it as a separate argument 
JSP Examples to the deploy tool. 

LDAP Demo 


Additional Samples <web-app xmlns-"http://geronimo.apache.org/xml/ns/j2ee/web-1.1"» 
<environment> 
<moduleId> 
<artifactId>MyApplication</artifactId> 
</moduleId> 
</environment> 


Figura 21. Testarea rulării serverului Geronimo 


Următoarea etapă este instalarea instrumentului Apache Axis2. Folosiţi consola 
de administrare Geronimo (numele de utilizator si parola in mod implicit sunt 
, system, respectiv ,,manager’) şi selectaţi opțiunea Deploy New. Testati desfăşurarea 
cu succes a operaţiunii, prin vizitarea adresei J//p:/ / localbost:8080/ axis2/. 

Din acest moment putem crea propriul nostru serviciu Web. Indiferent ce 
tehnologii folositi, existá douá abordari de dezvoltare: fie pornind de la docu- 
mentul WSDL ce descrie interfata serviciului (contract first approach), fie scriind 
codul-sursa al implementarii (code first approach). Prima metoda presupune buna 
cunoaștere a specificaţiilor WSDL (a se revedea capitolul 3). 

Mai simplu este să concepem o clasă Java si apoi să o transformăm în serviciu 
Web. În abordarea Axis2, după scrierea codului clasei mai urmează să precizăm 
așa-numitul descriptor al serviciului, memorat în fișierul services.xm/, și să creăm 
o arhivă de exploatare a aplicaţiei. 

Ne propunem să realizăm un serviciu simplu de salutare a utilizatorului: 

import org.apache.axis2.context.ServiceContext; 

import org.apache.axis2.context.OperationContext; 

public class HelloJavaSoap { 


public String echoJavaSoap(String param) { 
return "Echooo... " + param; 
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Am scris o clasă Java cu o singură metodă publică. Această metodă primește 
un parametru de tip string şi întoarce valoarea parametrului prefixată de un text. 

Urmează să creăm documentul services.xml care indică mediului cum să 
configureze și să expună posibililor clienti serviciul Web în cauză: 


<service name="HelloJavaSoap"> 

<description> 
Primul serviciu Web folosind Axis2 

</description> 

<parameter name="ServiceClass" locked="false"> 
HelloJavaSoap 

</parameter> 

<operation name="echoJavaSoap"> 
<messageReceiver class= 


"org.apache.axis2.rpc.receivers.RPCMessageReceiver" 
/> 
</operation> 
</service> 


Pentru a stabili corespondenta intre serviciu si clasa Java care il imple- 
mentează, am adăugat un atribut cu numele ServiceC/ass, a cărui valoare reprezintă 
calea spre locaţia unde se află memorată implementarea. Elementul operation 
specifică faptul că metoda oferită de serviciul Web este echoJavaSoap, mesajele 
fiind recepționate via clasa pusă la dispoziție de Apache Axis2. După cum se 
poate observa, se recurge la un transfer în stilul RPC. 

Următorul pas este să creăm o arhivă cu extensia .aar (Axis2 Archive) care 
include codul compilat (fișierul .c/ass) si documentul services. xp]. Structura interna 
a acestei arhive — de fapt, un .z/p cu extensie diferită — are forma: 


META-INFV 
Services.xml 
HelloJavaSoap.class 


Mai urmeazá sá incárcám serviciul prin interfata de administrare disponibilá 
la hitp:/ /localbost:8080/ axis2/ axis2-admin|/ , selectând opţiunea Upload Service (urmă- 
riti figura 22). 
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The Apache Software Foundation 
http://www.apache.org/ 


Tools 


Upload Service 
System Components Upload a AxisService Archive File 


Available Services 
Available Service Groups 


You can upload a packaged Axis 2 AxisService from this page in two small steps. 


Available Modules * Browse to the location and select the axisService archive file you wish| 
Globally Engaged Modules * Click Upload button 


Available Phases Simple as that! 


Execution Chains 


Global Chains Service archive : |E:\ExemplehHelloJavaSoap aar JL Browse... ) 
Operation Specific Chains Upload 


Engage Module 
For all Services 
For a Service Group 
For a Service 
For an Operation 

Services 
Inactivate Service 
Activate Service 
Edit Parameters 

Contexts 
View Hierarchy 


Figura 22. Incarcarea serviciului Web în vederea invocarii ulterioare 


După aceasta, dati clic pe legătura Available Services pentru a obţine mesajele 
din captura-ecran următoare: 


Tools 


Upload Service . : 
System Components Available Services 


Available Services 
Available Service Groups HelloJavaSoa 


Available Modules Service EPR : http://localhost:8080/axis2/services/HelloJavaSoap 
Globally Engaged Modules Service REST epr : http://localhost:8080/axis2/rest/HelloJavaSoap 


Available Phases 
Execution Chains 


Global Chaine I . Service Status : Active 
Operation Specific Chains | Engaged modules for the service 
Engage Module 


For all Services 
For a Service Group 


Service Description : This service is to get the running Axis version 


* addressing-1.0 


For a Service 
For an Operation Available operations 
Servi 
Ó— : * echoJavaSoap 
Inactivate Service 
Activate Service Engaged Modules for the Operation 
Edit Parameters o addressing-1.0 


Figura 23. Lista serviciilor disponibile (aici, serviciul Web HelloJavaSoap) 
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În cadrul distribuţiei Axis2, sunt disponibile o serie de exemple pe care le 
recomandăm spre studiu. Ne oprim asupra unui program, numit Dynamiclnvoker, 
care reprezintă un client Java pentru invocarea serviciilor Web (cel anterior, 
serviciile Web externe prezentate în secțiunea 2.5 etc.) pe baza documentului 
WSDL asociat. 

Pentru rularea acestui program, trebuie să stabilim valoarea corespunzătoare 
pentru variabila de mediu CLASSPATH, astfel încât să cuprindă locaţia unui 
procesor XML (eg., Apache Xerces) şi toate fişierele Jar din directorul #b. După 
compilarea codului, îl rulăm astfel: 

java samples.client.DynamicInvoker http://localhost:8080/ 


axis2/services/HelloJavaSoap?wsdl echoJavaSoap "avem 
portocale albastre!" 


Vom obţine următorul răspuns (am omis anumite mesaje de avertisment 
privitoare la lipsa suportului pentru jurnalizare /p24): 
Reading WSDL document from 'http://localhost:8080/ 
axis2/services/HelloJavaSoap?wsdl' 
Preparing Axis dynamic invocation 
Executing operation echoJavaSoap with parameters: 


>echoJavaSoap>param0=avem portocale albastre! 
>echoJavaSoapResponse>return=Echooo... avem portocale 
albastre! 


Done! 


Din cele prezentate mai sus, putem considera că mediul Ax/s2 oferă un 
mecanism flexibil și rapid de dezvoltare a serviciilor Web. Ca alternative, 
menţionăm JWSDP (Java Web Services Developer Pack) pus la dispoziţie de compania 
Sun si noua versiune J2SE 1.6, care include suport nativ pentru crearea si 
invocarea de servicii Web. 


Importarea serviciilor Web in Java 


Pe baza documentului WSDL ce descrie serviciul implementat in C# (a se 
revedea sectiunea 2.1), vom putea realiza asa-numita importare a interfetei lui in 
limbajul Java. Această acţiune poate fi realizată ușor, graţie instrumentului 
wsimport pus la dispoziţie de Java 2 Standard Edition — versiunea 1.6 (la momentul 
scrierii acestei cărți, am folosit varianta J2SE 1.6 beta 2). Rulându-l cu următorii 
parametri dati în linia de comandă, vom obţine în cadrul directorului xw/ 
codul-sursă Java al pachetului ro.nfoiasi.xmlvalidator ce desemnează interfața 
serviciului: 
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e:\jd 
xml-v 
ro\in 
ro\in 
ro\in 
ro\in 
ro\in 
ro\in 
ro\in 
ro\in 


foiasi 


\xml 
\xml 
\xml 
\xml 
\xml 
\xml 
\xml 
\xml 


va 
va 
va 
va 
va 
va 
va 
va 


lida 
lida 
lida 
lida 
lida 
lida 
lida 


lida 


k1.6.0\bin>wsimport http://localhost:8080/ 
alidator.asmx?WSDL -s .\xml -verbose 

foiasi 
foiasi 
oiasi 
foiasi 
foiasi 
foiasi 
foiasi 


tor\CheckIfExists.java 

tor NCheckIfExistsResponse. java 
tor\ObjectFactory.java 
tor\Validate.java 
tor\ValidateResponse.java 
tor\XMLValidator.java 
tor\XMLValidatorSoap.java 


tor\package-info.java 


Fisierul XMLVahdatorSoapjava contine definițiile metodelor — accesate via 
SOAP — expuse de serviciul Web si are următorul cod generat automat (din care, 
de altfel, se poate deduce și maniera de dezvoltare a serviciilor Web în J2SE 1.6): 


package ro.infoiasi.xmlvalidator; 


import javax.jws.WebMethod; 

import javax.jws.WebParam; 

import javax.jws.WebResult; 

import javax.jws.WebService; 

import javax.xml.ws.RequestWrapper; 

import javax.xml.ws.ResponseWrapper; 

// Numele si spatiul de nume al serviciului Web 

@WebService (name = "XMLValidatorSoap", 
targetNamespace = 

"http://www.infoiasi.ro/XMLValidator") 

public interface XMLValidatorSoap { 
// metoda care verifică existenţa fişierului 
@WebMethod(operationName = "CheckIfExists", 

action = 


"http://www.infoiasi.ro/XMLValidator/CheckIfExists") 
@WebResult (name 
targetNamespac 
"http://www.infoiasi.ro/XMLValidator") 

// desemnează clasa responsabilă cu incapsularea 


// cererii SOAP 


CheckIfExistsResult", 


QRequestWrapper(localName = "CheckIfExists", 
targetNamespac 
"http://www.infoiasi.ro/XMLValidator", 


// desemnează cl] 


className 


"ro.infoias 


i.xmlvalidator.CheckIfExists") 
lasa responsabilá cu incapsularea 


// ráspunsului SOAP 


@ResponseWrapper (localName = "CheckIfExistsResponse", 
targetNamespac 
"http://www.infoiasi.ro/XMLValidator", 


className 


"ro.infoiasi.xmlvalidator.CheckIfExistsResponse") 
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public boolean checkIfExists ( 
// meta-date pentru parametrul de intrare 
@WebParam(name = "filename", 
targetNamespace = 
"http://www.infoiasi.ro/XMLValidator") 
String filename); 
/* similar si pentru a doua metodá */ 


} 


Adnotările asociate serviciului Web sunt generate conform documentului 
WSDL si sunt disponibile în fişierul XMLValidator java: 


@WebServiceClient (name = "XMLValidator", 
targetNamespace = 
"http://www.infoiasi.ro/XMLValidator", 
wsdlLocation = 
"http://localhost:8080/xml-validator.asmx?WSDL") 
public class XMLValidator extends Service { 
private final static URL XMLVALIDATOR WSDL LOCATION; 
static { 
URL url = null; // adresa documentului WSDL 
try { 
url = new URL ( 
"http://localhost:8080/xml-validator.asmx?WSDL") ; 
} 
catch (MalformedURLException e) { 
e.printStackTrace(); 


XMLVALIDATOR WSDL LOCATION = url; 


public XMLValidator (URL wsdlLocation, 
QName serviceName) { 
super (wsdlLocation, serviceName) ; 


} 
public XMLValidator() { 
super (XMLVALIDATOR_WSDL LOCATION, 
new QName ("http://www.infoiasi.ro/XMLValidator", 
"XMLValidator")); 


} 


// se defineste punctul terminal al serviciului 
// (întoarce un obiect XMLValidatorSoap, 
// a cărui clasă a fost dată mai sus) 
@WebEndpoint (name = "XMLValidatorSoap") 
public XMLValidatorSoap getXMLValidatorSoap() { 
return (XMLValidatorSoap) super.getPort (new 
QName ("http://www.infoiasi.ro/XMLValidator", 
"XMLValidatorSoap"), XMLValidatorSoap.class) ; 
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Se remarcă existența pachetului javax.xm/ws disponibil începând cu J2SE 1.6 
si J2EE 1.5, care oferă suportul necesar dezvoltării facile si invocarii de servicii 
Web atât prin SOAP, cât si recurgand la paradigma REST. Acest pachet formează 
JAX-WS, interfaţa de programare de bază a serviciilor Web. 

Conform JAX-WS, un serviciu Web în rulare reprezintă o instanţă (obiect) a 
unei clase Java, adnotat prin javax.jws. WebService. Interfața expusă către posibilii 
clienți este o interfață Java privitoare la punctul terminal al serviciului (SEI — 
Service Endpoint Interface), care nu trebuie neapărat specificată de programator, 
deoarece ea poate fi suplinită de clasa care implementează serviciul. După 
scrierea codului și realizarea compilării, va putea fi creat un fişier .war care va fi 
exploatat în cadrul unui server de aplicaţii precum Tomcat. În timpul invocarii, 
serverul de aplicaţii va genera automat clasele responsabile cu schimbul de 
mesaje cu posibilii clienți. 

Similar manierei folosite la .NET, cel mai simplu serviciu Web (de salutare a 
utilizatorului) are codul următor: 


package salut; 


import javax.jws.WebMethod; 
import javax.jws.WebService; 


QWebService() 
public class Salut ( // clasá implementánd serviciul 


private String mesaj = new String("Salut, "); 


// o singurá metodá 

@WebMethod () 

public String sayHello (String nume) { 
return mesaj + nume; 


wa 


Corespunzător, clientul Java care invocă metoda de mai sus este compus din 
următoarele linii: 


import javax.xml.ws.WebServiceRef; 
import salut.ServiciuSalut; 
import salut.Salut; 


public class ClientSalut { 
@WebServiceRef (wsdlLocation- 
"http://localhost:8080/salutari/salutari?wsdl") 
static ServiciuSalut serviciu; 
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public static void main(String[] args) { 
try { 
ClientSalut client = new ClientSalut(); 
client.invoca(args); 


} 
catch(Exception e) { 
e.printStackTrace(); 


} 


// încearcă să invoce serviciul 


public void invoca (Stringll args) { 
try { 
System.out.println("Vom invoca " + serviciu); 
Salut port = serviciu.getHelloPort(); 


String nume; 
// preluăm numele din linia de comandă 
nume = (args.length > 0) ? 

args[0] : "Portocal Escu"; 
String raspuns = port.sayHello (nume); 
System.out.println(raspuns); 


} 
catch(Exception e) { 
e.printStackTrace(); 


2.8. Suportul oferit de mediul Delphi pentru crearea 
si utilizarea serviciilor Web 


Dezvoltarea serviciului 


La finalul acestui subcapitol vom prezenta maniera de implementare în Delphi 
(Object Pascal) a unui serviciu Web simplu. Codul-sursă a fost testat sub De/phi 
6 Enterprise Edition, care oferă suport pentru SOAP 1.1. 

Pentru crearea serviciului Web, avem la dispoziție un asistent (wizard) pe 
care-l putem apela prin intermediul operației O//er a opțiunii New din cadrul 
meniului Fre. Selectând zab-ul WebServices, vom da clic pe Soap Server Application. 
A se urmări figura de mai jos. 
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r 
|? New Items 


| Activex | Multitier | Forms | Dialogs | Projects | 
Business WebSnap WebServices 


«i Soap Server Application Creates a new Soap server application DLL or EXE 
H Soap Server Data Module Creates a new SOAP Data Module 


Bweb Services Importer Imports Web Service documents into Delphi 
$i | 
(« Copy C 


Cancel | Help | 


Figura 24. Apelarea asistentului de creare 
a unui serviciu Web 


Va apărea o fereastră în care trebuie să alegem tipul de aplicaţie ce va fi 
generată (vezi figura 25). Vom opta pentru realizarea unui executabil CGI care 
va putea fi ușor exploatat ulterior în cadrul serverului Apache. Drept alternative, 
ni se oferă posibilitatea să implementăm serviciul ca modul Apache ori ca o 
bibliotecă dinamică executată în cadrul unui server precum IIS. 


m 
New Soap Server Application 


You may select from one of the following types of World 
Wide Web server applications. 


© |SAPI/NSAPI Dynamic Link Library 
fi 


© Apache Shared Module (DLL) 
C Web App Debugger executable 


— — 


Cancel | Help | 


Figura 25. Alegerea tipului de aplicație Web 
care va incapsula serviciul dezvoltat 
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Mediul Delphi va genera un zzz, pe [fF "i TSalutwebModule 
care-l vom salva sub denumirea =) Published 
SWebMod.pas, care va ingloba trei com- C9 HTTPSoapDispatcherl 
ponente: C9 HTTPSoapPascallnvokerl 


; . © WSDLHTMLPublish1 
— HTTPSoapDispatcher! —  dispecerul | (02 variables/Constants 


SOAP peste HTTP, responsabil cu C9 SalutwebModule 
preluarea cererilor si trimiterea rás- |=- Uses 
punsului; 3 a 

— HTTPSoapPascallnvokerl — clasa respon- 3x SoapH TTPO 
sabila cu (de)serializarea mesajelor 3% SOAPHTTPPaslnv 
SOAP in obiecte Pascal; 2% SDAPPaslnv 

— WSDLHTMLPublish1 — clasa care gene- à SysUlils 
reazá descrierea WSDL a serviciului. f Ncc d 

u 


Acest modul Web are structura ilustrată de figura alăturată, iar codul lui sursă 
este furnizat în continuare: 


unit SWebMod; 


interface 
uses 
SysUtils, Classes, HTTPApp, WSDLPub, SOAPPasInv, 
SOAPHTTPPasInv, SoapHTTPDisp, WebBrokerSOAP; 
type 
( clasa responsabilá cu publicarea serviciului } 
TSalutWebModule = class (TWebModule) 
{ dispecerul SOAP peste HTTP } 
HTTPSoapDispatcherl: THTTPSoapDispatcher; 
{ clasa responsabilă cu (de)serializarea 
mesajelor SOAP în obiecte Pascal } 
HTTPSoapPascallnvokerl: THTTPSoapPascallInvoker; 
( clasa care genereazá doc. WSDL al serviciului } 
WSDLHTMLPublishl: TWSDLHTMLPublish; 
end; 


var 
SalutWebModule: TSalutWebModule; 


implementation 
(SR *.DFM} 
end. 
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Mai urmează sa scriem o clasă care va implementa efectiv serviciul Web dorit. 
Vom crea astfel wnit-ul salut.pas, al cărui cod este următorul: 


unit salut; 


interface 
uses InvokeRegistry; 
type 

( o interfață invocabilá } 

ISalut = interface (IInvokable) 
['(D7532EC7-EA7F-4610-ADE5-B3634BB0OF343)]'] 
function Salut: String; stdcall; 
function NumaraZile: Byte; stdcall; 

end; 

{ o clasá implementánd interfata ] 

TSalut = class (TInvokableClass, ISalut) 

public 
( metodel xpuse de serviciul Web } 
function Salut: String; stdcall; 
function NumaraZile: Byte; stdcall; 

end; 


implementation 
uses SysUtils, DateUtils; 
{ implementarea metodelor serviciului Web } 
function TSalut.Salut: String; stdcall; 
begin 

Result := 'Salut din Delphi, prin SOAP!'; 
end; 


function TSalut.NumaraZile: Byte; stdcall; 

begin 
Result := DaysBetween (Now, 

EncodeDate(2006, 12, 31)); 


end; 


initialization 
{ inregistrarea interfetei si clasei } 
InvRegistry.RegisterInterface (TypelInfo(ISalut)); 
InvRegistry.RegisterInvokableClass (TSalut); 

end. 


Dupá cum se observa, specificám pentru inceput o interfatá invocabila, avand 
douá metode ce vor fi expuse de cátre serviciul Web de fatá. Acestei interfete i 
se asociazá un identificator universal unic, in maniera componentelor COM. De 
asemenea, oferim si o implementare via o clasá invocabila. Sunt definite douá 
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funcţii, una care întoarce un mesaj (şir de caractere) de salut, cealaltă oferind 
numărul de zile (un întreg de tip By) rămase din momentul execuţiei până la 
finalul anului 2006. 

Cele două wnit-uri le includem în proiectul cu numele SalutW S.dpr şi generám 
fişierul executabil. Pentru a putea fi efectiv utilizat, acesta din urmă trebuie 
plasat în directorul //docs al serverului Apache pentru Windows (in cazul nostru, 
folosim distribuția Apache2Triad). Mai trebuie să configurám serverul să trateze 
fişierele executabile (cele cu extensia .exe) ca programe CGI. Pentru aceasta vom 
edita fişierul Attpd.conf (localizat în directorul conf al serverului), inserand in 
secțiunea «IfModule mod cgi.c»...«/IfModule» liniile de mai jos: 


AddHandler cgi-script .exe 
AddType application/x-httpd-cgi .exe 


Putem testa funcționalitatea serviciului folosind adresa ///p:/ / localbost/ SalutW/S. exe/ 
wsdl/ ISalut într-un browser Web. Va trebuie să obţinem fişierul WSDL generat 
automat de program (avizăm cititorul că formatul WSDL nu respectă standardele 
în vigoare, ci o versiune mai veche a specificatiei, actualmente considerată 
demodată). 


Un client Delphi pentru serviciul implementat 


Object Inspector 


În continuare, vom detalia maniera de exploa- 
tare a serviciului printr-un client Delphi. Vom Properties | Events | 

crea un form pe care vom plasa un buton de — [miConverter HTTPRIO.Converte 
execuţie, la apăsarea căruia să se invoce metoda HHT TPWebNod HTTPRIO.HTTPW 


NumaraZile a serviciului de mai sus. De ase- Name HTTPRIO 
Port ISalutPort 


C t Palett al Service \Salutservice vY 
nente (Component Palette), vom alege componenta T Tp mem 


HTTPRIO, responsabilă cu transferurile de URL 
date aflate la distanţă via HTTP. In fereastra WSDLLocation http: //localhost/5a 
Object Inspector, va trebui să edităm valorile 


menea, din /zb-ul WebServices al barei de compo- 


următoarelor proprietăţi asociate componentei 
amintite (a se urmări cele din figura alăturată): 


— WSDLLocation — reprezintă locaţia fișierului 
WSDL asociat serviciului (putem introduce 
URL-ul Aitp://localhost/ SalutW/S.exe/ wsdl/ 
ISalut); 

— Service — desemneazá numele serviciului 
(mediul genereazá o listá de optiuni pe 
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baza locatiei WSDL de mai sus, astfel incat vom selecta pentru situatia de fata 
unica intrare [Sa/utservice); 

— Port — reprezintă punctul terminal al serviciului (ca și mai sus, din lista 
generată, alegem [Sa/utPort). 


Pentru a putea utiliza efectiv serviciul Web via HTIPRIO, va trebui să 
recurgem la un alt asistent, denumit Web Services Importer (vezi figura 24), 
responsabil cu generarea unui niż de accesare a metodelor puse la dispoziţie de 
serviciu. Asistentul va solicita adresa Web ori numele de fișier local al docu- 
mentului WSDL corespunzător serviciului importat. La apăsarea butonului 
Generate va fi creat un unit, pe care-l denumim Sa/utImport.pas. Codul-sursă al 
acestuia este urmatorul: 


unit SalutImport; 


interface 
uses Types, XSBuiltIns; 
type 

{ interfata invocabilá } 

ISalut = interface(IInvokable) 
['(AE775C10-3E55-41C4-8494-2A57E658F959] '] 
function Salut: WideString; stdcall; 
function NumaraZile: Byte;  stdcall; 

end; 


implementation 

uses InvokeRegistry; 

initialization 
( inregistrarea interfetei } 
InvRegistry.RegisterInterface(TypeInfo(ISalut), 


'urn:salut-ISalut', ''); 
end. 


Mai urmeazá sa scriem liniile care realizeaza efectiv invocarea, folosindu-ne 
de interfaţa ISa/ur 


unit SalutClient; 

interface 

uses 
Windows, Messages, SysUtils, Variants, Classes, 
Graphics, Controls, Forms, 
Dialogs, Rio, SoapHTTPClient, StaCtrls; 

type 
{ fereastra de dialog } 


TFormClient = class (TForm) 
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buton: TButton; 
HTTPRIO: THTTPRIO; 
procedure butonClick(Sender: TObject); 
end; 
var 
FormClient: TFormClient; 
implementation 
{SR *.dfm} 
uses SalutImport; 


{ procedura de tratare a apăsării butonului } 
procedure TFormClient.butonClick (Sender: TObject); 
var Salut: ISalut; 
begin 
try 
Salut := (HTTPRIO as ISalut); 
{ afişăm rezultatul primit de la metoda 
serviciului Web invocat ) 


MessageDlg('Au mai rămas ! + 
IntToStr(Salut.NumaraZile) + ' de zile.', 
mtInformation, [mbOk], 0); 

except 
on E: Exception do { tratăm erorile } 
MessageDlg('A apărut o eroare:' + E.Message, 
mtError, [mbAbort], 0); 
end; 
end; 
end. 


După compilare, vom putea testa programul așa cum se poate remarca din 
captura-ecran de mai jos: 


Client SOAP 


Figura 25. Interfafa-utilizator a clientului de invocare a serviciului Web 
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Invocarea din PHP a serviciului implementat in Delphi 


La finalul acestei sectiuni vom concepe un program PHP care va recurge la 
extensia Soap pentru apelarea metodelor serviciului de mai sus. Ca si in exemplele 
anterioare, codul-sursă este simplu: 


Sclient = new SoapClient (null, 
array('location' => 
'http://localhost/SalutWS.exe/soap/ISalut', 
'uri' => 'urn:salut-ISalut')); 
$rez = S$Sclient-»  call('Salut', array()); 


echo "«p»Am primit mesajul: 
<strong>$rez</strong></p>"; 

Șzile = Șclient->__call('Numarazile', array()); 

echo "<p>Au mai rămas Șzile de zile până la 
finalul anului.</p>"; 


După cum se remarcă, serviciul Web este disponibil la adresa ///p:/ / localbost/ 
SalutW'S.exe/ soap/ ISalut, spaţiul de nume fiind automat generat de mediul Delphi. 
Un posibil rezultat poate fi urmărit în figura 26. 


©) Un client SOAP - Mozilla Firefox 
File Edit View Go Bookmarks Tools Help 


@-®- ej € A & & E http: /localhost/php-delphisalut-client. php v 


x Disable” |a| Cookies" DV C55» ©) Formsy 3^ Images" ® Information" Miscellang 
|_| http:Z/localhost/S.. wW'S.exe/wsdl/lS alut | L] Un client SOAP | 


Am primit mesajul: Salut din Delphi, prin SOAP! 


` 


Au mai rămas 122 de zile până la finalul anului. 


Done © QE (C) Derors / 0 wamings 


Figura 26. Rezultatul obtinut după execuția metodelor serviciului Web 
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3. Invocarea serviciilor Web in contextul AJAX 


3.1. Punerea problemei 


Având la dispoziţie serviciul Web privitor la operaţii cu fișiere (prezentat anterior 
în cadrul acestui capitol), am dori să verificăm în mod asincron existenţa unui 
fişier, pe baza numelui furnizat de utilizator via un formular electronic. Graţie 
AJAX (Asynchronous JavaScript And XML), aceasta se poate realiza fără a reîncărca 
întreaga pagină Web. Pe baza unor date preluate de pe servere aflate la distanţă, 
se poate reactualiza în manieră dinamică arborele DOM (Document Object Model) 
asociat documentului XHTML redat de programul de navigare. 

După o succintă prezentare a suitei de tehnologii AJAX, vom furniza detaliile 
de implementare a unui sept PHP care va reprezenta puntea de legătură între 
documentul Web încărcat în browser și serviciul Web scris în Perl. 


3.2. Caracteristici importante ale suitei de tehnologii AJAX 


Componente 


Termenul AJAX desemnează o suită de tehnologii deschise, încorporând urma- 
toarele: 


— diverse limbaje standardizate de prezentare a datelor, precum XHTML și CSS 
(Cascading Style Sheets); 

— redarea si interactiunea via standardul DOM; 

— interschimbul și manipularea de date prin XML și/sau XSLT (Extensible 
Stylesheet Language Transformations); 

— transferul asincron de date via obiectul XMLHZ/pRequest; 

— procesarea prin limbajul ECMAScript/JavaScript. 


Daca aplicaţiile Web convenţionale erau construite având ca punct central 
serverul, navigarea fiind bazată pe încărcarea de pagini Web (cu conţinuturi 
statice sau generate dinamic) solicitate serverului, în cazul AJAX aplicaţia rezidă 
chiar în cadrul paginii, procesarea având loc la nivelul clientului, iar o parte din 
date sunt stocate tot de către acesta. Astfel, avantajele majore aduse de AJAX 
sunt cele legate de eliminarea reincárcárii paginilor, de facilitarea interacțiunii cu 
utilizatorul, de micșorarea timpilor morti etc. Din punctul de vedere AJAX, 
întreaga aplicaţie se regăseşte la nivelul browser-ului, ceea ce poate avea 
repercursiuni nedorite privind sincronizarea serverului cu clientul. De cele mai 
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multe ori este practic imposibil să se cunoască starea (comportamentul) pro- 
gramelor de pe server. Alte dezavantaje vizează dependenţa de tehnologia 
JavaScript (implementată in mod diferit de fiecare browser în parte), dificultatea 
testării și depanării aplicaţiilor, necesitatea folosirii navigatoarelor de ultimă 
generaţie, accesul oricui la codul-sursă (ceea ce poate cauza probleme de 
securitate) si imposibilitatea, în unele situaţii, de a realiza bookmark-uri ori de a 
folosi mecanismul de istoric al navigării (history). 

Succesul suitei de tehnologii AJAX provine din promovarea sa de către 
aplicații Web populare precum Amazon, Basecamp, Flickr, Gmail, Google Maps, 
Google Suggest, Netflix, Rollyo, Writely, Yahoo! şi Zimbra. 


Obiectul XMLHttpRequest 


Componenta de bază este obiectul XMLHpRequest pus la dispoziţie practic de 
către orice browser Web actual (a apărut în premieră ca obiect ActiveX inclus în 
Internet Explorer 5, iar apoi a fost adoptat și de Mozilla 1.0 si Safari 1.2). Acest 
obiect permite realizarea de cereri HTTP (eg, GET si POST) dintr-un program 
rulând la nivel de client (program de navigare) spre o aplicaţie de pe server, 
într-un mod asincron. 

În mod uzual, datele vehiculate între programele client și server sunt marcate 
în XML, dar pot fi adoptate si alte abordări: reprezentări HTML, JSON (JavaScript 
Object Notation), CSV (Comma Separated Values) ori diverse metode de serializare. 
Atunci cand se utilizeaza HTML ca mijloc de reprezentare a datelor, AJAX se 
mai numește si AHAH (4ynchronous HTML and HTTP). JSON reprezintă un subset 
al limbajului JavaScript (in fapt, al versiunii standardizate, cunoscuta sub numele 
de ECMAScript), avantajul fiind ca datele reprezentate in JSON sunt simple 
şiruri de caractere ce pot fi convertite ușor in (tablouri de) obiecte JavaScript. 
Astfel dispare necesitatea procesării conţinutului XML obţinut de la server. 

Principalele metode care vor fi folosite efectiv în contextul AJAX sunt 


următoarele: 


— open() iniţiază (deschide) o conexiune HTTP cu serverul, trimițând o cerere 
(uzual, GET sau POST) către acesta; aplicația de pe server cu care va avea loc 
schimbul de date va fi desemnată de un URI, după cum vom vedea mai jos; 

— send() transmite date, în manieră asincronă, către aplicaţia rulând pe server; 

— abort() abandonează transferul curent; 

— setRequestHeader() specifica diverse câmpuri ale antetului HTTP; de exemplu, 
se poate stabili o anumită valoare particulară pentru câmpul Content-Type, 
aspect util atunci când dorim să manipulăm alte tipuri de conţinuturi, de 
exemplu JSON ori CSV. 
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Proprietatile de baza ale obiectului sunt: 


— readyState contine codul de stare a transferului (eg., valoarea 4 specifică 
faptul ca transferul datelor s-a efectuat complet) — a se consulta si tabelul 
de mai jos; 


Valoarea 


St D i 
red dy State are escriere 


Obiectul XML a fost creat, dar procesul de incar- 
care nu a fost încă pornit. 


0 UNINITIATED 


Încărcarea este in progres, dar analiza XML nu a 


LOADING A 
început. 


Încărcarea s-a terminat, însă arborele DOM nu a 
fost creat. 


LOADED 


Arborele DOM a fost generat, dar numai o parte 


UIC E dintre elemente au fost analizate. 


Documentul XML a fost complet încărcat şi ana- 


COMPLETED |. 
lizat. 


— status reprezintă codul de stare HTTP întors de serverul Web; de exemplu, 
200 (OR), 404 (Not Found), 500 (Server Internal Error); 

— statusText desemneaza sirul de caractere ce explica in limbaj natural codul de 
stare obtinut; 

— onreadystatechange specifică funcţia ce va fi invocată la modificările privind 
schimbarea stării de transfer a datelor (datele sunt transmise în manieră 
asincronă si deci programul de la nivel de client trebuie să poată fi notificat 
asupra schimbării evenimentelor care pot surveni pe parcursul transferului). 


Utihizari 
Caracteristica importanta oferita de AJAX este cea de a schimba doar anumite 
parti ale paginii Web. 

Una din tehnicile AJAX populare este si cea a indicarii vizuale a faptului că 
un fragment dintr-un document a fost modificat. Astfel, pe baza unei nuante de 
culoare, care dispare in timp, utilizatorului i se poate semnala că un paragraf 
dintr-un text are conţinutul schimbat (actualizat). Uzual, se folosește galbenul; 
de aceea, acest șablon de proiectare se mai numește si YFT (Yellow Fade Technique), 
generalizarea sa intitulandu-se FAT (Fade Anything Technique). 

O alta utilizare este cea a reimprospatarii automate (eventual, periodice) a 
unei zone dintr-o pagină. De exemplu, atunci când a apărut o nouă știre 
receptionata via un emiţător Atom/RSS (Really Simple Syndication) oti s-a modificat 
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o informatie de interes pentru utilizator (curs valutar, temperatura, scor la un 
meci, voturi acordate unei piese muzicale etc.). 

Tot prin intermediul AJAX, putem realiza un câmp interactiv cu auto- 
completarea datelor (auto-completion), în funcţie de cele introduse deja de către 
utilizator. Astfel se emulează bine-cunoscutul control combo-box, oferindu-se o 
listă de sugestii în funcție de caracterele tastate. Situl Google Suggest folosește 
intensiv această tehnică. În acest context, putem menţiona că AJAX ne poate 
sluji și pentru validarea diverselor informaţii obţinute de la utilizator. 

Altă facilitate uşor de implementat via AJAX este cea de a oferi posibilitatea 
efectuării de operaţii drag-and-drop asupra unor zone prestabilite ale paginii Web. 
In conjunctie cu o bibliotecă JavaScript precum DOM-Drag, se poate astfel 
implementa — la nivel de aplicație Web — un comportament similar unei 
interacțiuni convenţionale de tip MDI (Multiple Document Interface). 

Diverse alte intrebuintari ale AJAX sunt dedicate realizarii de efecte vizuale 
(unele dintre ele, sofisticate), similare interactiunii cu utilizatorul in Mac OS X 
sau Windows Vista. 


Instrumente de dezvoltare 


Actualmente sunt disponibile diverse cadre de lucru dedicate dezvoltării apli- 
catiilor AJAX. La nivelul clientului pot fi folosite diferite biblioteci (eg., Dojo, 
Prototype, Rico ori Script.aculo.us), unele dintre ele oferind și suport pentru manipu- 
larea facilă a arborilor DOM. Pe partea de server se poate recurge la tehnologii 
precum CGI, servere de aplicaţii (de exemplu, programe PHP sau serv/et-uri) ori 
framework-uti dedicate — vezi mai jos. 

Trebuie menţionat faptul că o serie de companii deja au început să pună la 
dispoziţie interfeţe de programare AJAX specializate, pentru ca dezvoltatorii să 
integreze facil conţinuturi provenite de pe diverse situri în cadrul paginilor 
proprii. Un exemplu notabil este Google AJAX Search API, prin care se poate 
avea acces la serviciul Web de cautare direct la nivel de client, in stilul AJAX. 
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Ele Edit View Go Bookmarks Tools Help 
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Mail 


Dosios a: source demo 
Simple Mail Application demonstration 


| 4 Get Mail | | Wf New Message | 


EHM Mail Account 
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Sentai | Adam Arlen 


į Deleted | Bob Baxter 


i A TT — 
1-4 Saved Mail Carrey ana Sending/Receiving Composition 
David Davis TE AS Le 
Server: localhost] | 
This is a simple a ojo ^ 
widgets: 
e F, 
e split pane 1» 
+ floating pare A 
+ layout pane 
* tree 
+ button 
+ TabContainer 
+ editor 
Click on the messages in the Inbox, or try to edit the options 
or create a new message. There's no server running, so the 
app is just a facade and it doesn't really do anything. 2 
Done / E ) 


Figura 27. O aplicație Web demonstrativă construită cu biblioteca Dojo 
folosind diverse tehnici AJAX 


3.3. Invocarea asincronă a unui serviciu Web via AJAX 


Folosirea efectivă a obiectului XMLHttpRequest şi a unui intermediar scris ín PHP 


Vom considera scenariul: un utilizator dorește să verifice existenţa unui fișier 
aflat pe un server, pentru aceasta trebuind să completeze un formular care îi va 
solicita numele fișierului în cauză. Prin intermediul AJAX, vom apela un program 
PHP ce va reprezenta un client pentru serviciul Web privitor la operaţii cu 
fișiere, detaliat în subcapitolul 1. 
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La apariția evenimentului de pierdere a focus-ului asupra câmpului de intro- 
ducere a numelui de fisier, prin intermediul unui program JavaScript se va realiza 
un transfer asincron catre programul PHP ruland pe server, aplicatie care va 
întoarce răspunsul privind existenţa numelui de fişier. In acest caz, utilizatorul va 
primi imediat feedback pozitiv, suplimentar având posibilitatea redenumirii fisie- 
rului respectiv. 

Formularul Web de interacţiune cu utilizatorul are următoarea structură: 


<form action="redenumire.php" method="get"> 


Numele fisierului : <input type="text" name="nume" 
title="Introduceti un nume de fisier" 
onblur= 
"javascript:verificaExist (this.value, '')" /> 


<span class-"ascuns" id="fisierExistent"> 
Fisierul există. 
<input type="checkbox" value="da" 
name="redenumire" checked="checked" 
title="Bifati daca doriti redenumirea 
fişierului" />Redenumim? 


</span> 
<br /><input type="submit" value-"Executá" /> 
</form> 


În cadrul unui element <span> vom insera construcţiile XHTML ce vor 
contine mesajul afișat utilizatorului în cazul în care fişierul există, putându-se 
bifa opţiunea de redenumire a acelui fișier. Iniţial, acest element va fi ascuns și 
va fi afişat prin modificarea proprietăţii de stil disp/ay oferită de CSS. 

Clasele de proprietăți CSS sunt specificate în antetul documentului XHTML 
în maniera de mai jos: 

input [ltype="text"]:focus { 


background: #EEE; 
border-color: #000; 


} 
„exista { /* pentru semnalarea exist. fişierului */ 
display: block; 
background: #CCE; 
border-width: 1px; 
border-style: dotted; 
padding: 0.2em; 
width: 233px; 
} 
„ascuns { /* pentru ascunderea mesajului */ 
display: none; 


wa 
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La apariția evenimentului ogb/ur va fi apelată funcția JavaScript verificaExist() 
care va avea ca responsabilitate efectuarea transferului asincron către un program 
PHP rulând pe server ce va apela metoda de verificare a existenţei fişierului, 
metodă implementată de serviciul Web conceput în limbajul Perl. Atât cererea, 
cât şi rezultatul obţinut vor fi marcate in XML. 

Codul-sursa al funcției verificaExist() este următorul: 


function verificaExist (nume, raspuns) | 
// avem un răspuns? 
if (raspuns != '') | 
// preluăm via metodele DOM 
// elementul cu id-'fisierExistent' 
// pentru a afişa mesajul dorit 
mesa) = document.getElementById ('fisierExistent'); 
// schimbăm stilul de afişare (în caz de succes 
// vor fi aplicate proprietăţile CSS din 
// clasa 'exista', altfel textul va fi ascuns) 


mesa) .className = 
(raspuns == 1) ? 'exista' : 'ascuns'; 


} 

else { 
// nu e nici un răspuns setat, vom verifica 
// trimițând o cerere asincronă către server 
incarcaXML ('/verifica exist.php?nume-' + nume); 


Cererea asincroná către programul PHP va fi realizată de funcția zmcarea XM L() 
avand codul dat in continuare: 


var cerere; // cererea cátre serverul Web 
// încarcă un document XML desemnat de 'url' 
function incarcaXML (url) { 
// verificám existenta obiectului XMLHttpRequest 
if (window.XMLHttpRequest) { 
// existá suport nativ (Mozilla Firefox) 
cerere - new XMLHttpRequest (); 
// se stabileste functia de tratare 
// a stării încărcării 
cerere.onreadystatechange = trateazaCererea; 


// preluăm documentul prin metoda GET 
cerere.open ("GET", url, true); 
cerere.send (null); 
} 
else if (window.ActiveXObject) | 
cerere = new ActiveXObject ("Microsoft.XMLHTTP"); 


= 


// se poate folosi obiectul ActiveX din MSIE 
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if (cerere) { 
// preluăm documentul prin metoda GET 
cerere.onreadystatechange = trateazaCererea; 


cerere.open ("GET", url, true); 
cerere.send (); 


Se verifică disponibilitatea obiectului XMLH#pRequest în cadrul navigatorului 
Web, iar maniera de transfer se va realiza prin metoda GET a protocolului 
HTTP. Tratarea evenimentelor de transmisie asincronă a datelor are loc in 
funcția 7rafeazaCererea() a cărei implementare este furnizată mal jos: 


function trateazaCererea () | 
// verificám dacă încărcarea s-a terminat cu succes 
if (cerere.readyState == 4) { 
// verificám dacă am obţinut codul de stare '200 Ok' 
if (cerere.status == 200) { 
// procesăm datele receptionate (preluăm via DOM 
// elementul-rádáciná al documumentului XML) 
raspuns = cerere.responseXML.documentElement; 
metoda = raspuns.getElementsByTagName ( 
'metoda')[0].firstChild.data; 
rezultat = raspuns.getElementsByTagName | 
'rezultat')[0].firstChild.data; 
// evaluám metoda 
eval ( metoda + '(\'\', rezultat)'); 
} 
// se pot trata si alte coduri (404, 500 etc.) 
else { 
alert ("A apărut o problemă la transferul XML:\n" 
+ cerere.statusText) ; 


Datele XML care vor fi recepționate reprezintă un nume de metodă — în 
acest caz, verificaHxist() — si rezultatul întors de aceasta. Aceste date vor fi 
prelucrate doar în caz de succes (codul de stare HTTP va fi 200). 

Programul PHP ce verifică existenţa fișierului pe baza numelui recepționat de 
la utilizator via AJAX are următorul cod-sursă: 

<?php 

require once('lib/nusoap.php'); 

// trimitem tipul continutului 
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header ('Content-type: text/xml!); 


// funcţie care verifică dacă există un fişier 


function verifica (Snume) { 


) 


// instantiem un client SOAP 

Sclient = new soapclient ( 
'http://endirra.ro:3333/xml-files.pl'); 

// preluám posibilele erori 

Seroare = Sclient->getError(); 


if (Seroare) 
return 0; 
// stabilim parametrii de intrare ai metodei invocate 


Sparam = array('filename' => $nume); 
// stabilim spatiul de nume folosit 
$spatiu nume = 'http://127.0.0.1:3333/XMLFiles/'; 


// realizám apelul 
Srezult = Sclient->call('CheckIfExists', 
array('parameters' => Sparam), 
$spatiu nume, '', true); 
// verificám dacá existá vreun fault 
if (Sclient->fault) 
return 0; 
// eroare la executie? 
Seroare = Sclient->getError(); 
if (Seroare) 
return 0; 
// întoarcem rezultatul oferit de metoda invocată 
return Srezult; 


// generám conținutul XML 
echo '«?xml version="1.0" ?>'; 


2> 


<raspuns> 


<metoda>verificaExist</metoda> 
<rezultat> 

<?php echo verifica ($ REQUEST['nume']); ?> 
</rezultat> 


</raspuns> 


Trebuie invocată metoda CheckIfExists implementată de serviciul Web creat in 


Perl. 


Programul PHP recurgând la functionalitatile oferite de biblioteca N4SOAP 
devine în acest moment client al serviciului, funcționând ca un intermediar între 


script-ul JavaScript ruland în browser și serviciul Web executat pe un server aflat 


la distanţă. Cele trei categorii principale de entități de calcul implicate in aceasta 


acţiune sunt ilustrate de figura 28. 
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XmlHttpRequest 
(transfer asincron) 
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i —_ 
Script 
PHP 


Server Web 


client al serviciului Web 


Transfer HTTP sincron 


: 

[^] 

= Script 
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E Sistem de 
a Serviciu Web iere 


Figura 28. Re/agüle între programul JavaScript, sctipt-ul PHP 
şi serviciul Web implementat in Perl 


Tipul conţinutului generat va fi XML, așteptat pe partea de client de către 
programul JavaScript. 

Figura următoare reprezintă o captură-ecran oferind mesajul obţinut de 
utilizator în cazul în care introduce un nume de fișier existent, cu posibilitatea 
redenumirii acestuia. 
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Numele fisierului: ae 


Figura 29. Mesajul obtinut în urma introducerii unui nume de fisier existent 


Apeland script-ul PHP in mod explicit — introducând in browser o adresă de 
genul bztp:/ / endirra.ro/ verifica_exist.php?filename inexistent —, obţinem documentul 
XML ilustrat de figura 30. Acest document încapsulează de fapt răspunsul 
prelucrat în cadrul programul JavaScript descris anterior. 


Address http: //endira.ro/verifica_exist. php ?filename=inexistent 


<?xml versionz"1.0" ?> 
- <raspuns> 


<metoda>verificaExist</metoda> 
<rezultat>O</rezultat> 
«/raspuns» 


Figura 30. Documentul XML furnizat de programul PHP 
de verificare a existenței unui fisier 


Din cele descrise mai sus, se poate observa faptul că serpr-ul PHP funcţionează 
ca un intermediar (prox)), realizând inter-operabilitatea între programul JavaScript 
rulat în cadrul browser-ului si serviciul Web Perl invocat pe un server diferit de 
cel în care se execută codul PHP. Am ales modelul descris aici, deoarece serviciul 
Web poate să nu fie disponibil pe aceeași mașină pe care rulează codul PHP 
invocat prin obiectul XMLH//pRequest. 

La apăsarea butonului de tip submit va fi apelat script-ul redenumire.php, care va 
trebui să invoce metoda de redenumire a fișierului, metodă implementată de 
serviciul Web. Scrierea acestui program rămâne ca temă de acasă pentru cititorul 
interesat. 


3.4. Utilizarea bibliotecii Prototype 


O soluţie alternativă la precedenta este aceea în care recurgem la biblioteca 
Prototype, care pune la dispoziţie o suită de clase și extensii DOM (Document Object 
Model) pentru facilitarea unei interacțiuni Web flexibile pe partea client, în 
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JavaScript. Una dintre functionalitatile pe care o vom utiliza se referă tocmai 
la implementarea unui mecanism robust, independent de navigator, de transfer 
asincron de date in stilul AJAX. Astfel, pagina Web care solicita utilizatorului 
un nume de fișier pentru a verifica existenţa sa pe server are următorul 
cod-sursá: 


<!DOCTYPE html 
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
"http://www.w3.org/TR/xhtml11/DTD/xhtmll-strict.dtd"» 
«html xmlns-"http://www.w3.org/1999/xhtml" 
lang="ro" xml:lang="ro"> 
<head> 
<title>AJAX + SOAP</title> 
<style type="text/css"> 
„exista { /* pt. semnalarea existenţei fişierului */ 
display: block; 
background: #CCE; 
border-width: 1px; 
border-style: dotted; 
padding: 0.2em; 
width: 233px; 


} 
„ascuns { /* pt. ascunderea mesajului */ 
display: none; 
) 
</style> 
<!-- folosim biblioteca Protoype 1.4.0 --> 
<script type="text/javascript" 
src="prototype.js"></script> 
<script type="text/javascript"> 
// lista de tratare a evenimentelor 
// de încărcare asincroná 
var globalHandlers = { 
// la crearea conexiunii cu serverul 


onCreate: function () { 
// afişăm un mesaj temporar 
Element.show ('asteptare'); 


}, 
// la aparitia unei erori 
onFailure: function() { 
alert ('Eroare de transmitere.'); 


), 
// la aparitia unei exceptii 
onException: function() { 
alert ('A apărut o exceptie.'); 
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// funcţie care verifică existența 
// numelui de fişier via AJAX 
function verificaExist () { 
// înregistrăm funcțiile de tratare a evenimentelor 
Ajax.Responders.register (globalHandlers); 
// instantiem obiectul AJAX 
var obAjax = new Ajax.Request ( 

'/ajax/verifica exist.php', // URI-ul invocat 

{ 
method: 'get', 
// parametrii transmişi spre server 
parameters: 'nume=' + SF('nume'), 


// metoda apelată la terminarea transferului 
onComplete: afiseaza 


)); 


// functie responsabilá cu afisarea rezultatului 
function afiseaza(rasp) ( 

// ascundem mesajul temporar 

Element.hide ('asteptare'); 

// preluám valoarea rezultatului 

// printr-o expresie regulatá, 

// deoarece ráspunsul e un sir de caractere 
var pattern - 
new RegExp("\<rezultat\>1\<\/rezultat\>"); 
// modificám clasa CSS corespunzátoare 

// elementului «span» initial ascuns 


S('fisierExistent').className = 
(pattern.test(rasp.responseText)) ? 
"exista! : 'ascuns'; 
} 
</script> 
</head> 
<body> 
<form action="redenumire.php" method="get"> 
Numele fisierului : <input type="text" id="nume" 
title="Introduceti un nume de fisier" 
onblur="javascript:verificaExist ()" /» 


<span id="asteptare" 
style="display:none; color: #990; font-style:italic"> 
Aşteptaţi, vă rugăm...</span> 
<span class="ascuns" id="fisierExistent"> 
Fisierul există. 
<input type="checkbox" value="da" 
name="redenumire" checked="checked" 
title="Bifati daca doriti redenumirea 
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fişierului" />Redenumim? 
</span> 
<br /> 
<input type="submit" value-"Executá" /> 
</form> 
</body> 
</html> 


Evenimentele privitoare la desfasurarea transferului de date intre client si 
setver pot fi tratate de functii definite de utilizator. In cazul de fata, la crearea 
unui conexiuni cu serverul, vom afișa un mesaj temporar ce semnalează utiliza- 
torului faptul că trebuie să aștepte primirea răspunsului (a se vedea figura 31). 


Numele fisierului : inexistent Asteptati, va rugam... 


Figura 31. Semnalarea unui mesaj de aşteptare 
a realizării unui transfer asincron via AJAX 


Maniera de afișare /ascundere a unui element — <span id="asteptare"> 


este realizată de metodele show(), respectiv /ide() ale clasei E/ement definite de 
biblioteca Prototype. În caz de eroare (onFailuré) sau de excepţie (onHxception), vom 
semnala această situaţie utilizatorului via funcţia JavaScript standard a/er/(). Ca si 
în exemplul anterior, verificarea existenţei fișierului se realizează în cadrul funcţiei 
verificaExist(). În această situaţie, vom instantia un obiect Ajax. Request ce repre- 
zintă cererea efectuată de program către server, după ce în prealabil am înregistrat 
funcţiile de tratare a evenimentelor de transfer via Ajax. Responders.register(). 
Argumentele constructorului Ajax. Request() sunt, in mod firesc, adresa serpr-ului 
PHP ce va fi invocat pe server (același program ca mai sus), metoda HTTP 
folosită, parametrii de intrare (în cazul nostru, numele fișierului) și funcţia ce va 
fi apelată la finalizarea transferului asincron. Valoarea numelui de fișier este 
preluată din formular prin intermediul construcției $F() specificate de Prototype. 
În acest mod, putem accesa comod câmpuri din formularele Web. 

După obţinerea rezultatului va fi executată funcția afiseaza(), care are drept 
argument un obiect conţinând răspunsul primit din partea serverului, în cazul 
nostru, un document XML. Proprietatea responseText reprezintă şirul de caractere 
recepționat din partea snprului PHP, adică documentul XML ilustrat în figura 30. 
Printr-o expresie regulată simplă, preluăm valoarea elementului <rezultat>, 
pentru a schimba clasa CSS corespunzătoare marcatorului <span> responsabil 
cu semnalarea existenţei fișierului și inserării butonului de bifare a redenumirii 
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acestuia. Construcţia §() este o scurtáturá pentru metoda getEmentByld() spe- 
cificată de recomandarea DOM, fiind folosită pentru a selecta un anumit element 
din cadrul documentului XHTML; a se revedea și capitolul 2. 

O capturá-ecran a dialogului între client si server este pusă la dispoziţie de 
figura 32, in care se poate remarca și interfața extensiei Frrebug pentru navigatorul 
Firefox, folosită în situaţia de fata pentru a lista apelurile AJAX realizate si 
posibilele erori survenite. Această extensie poate fi utilizată cu succes pentru 
depanarea oricăror programe JavaScript. 


" 
©) AJAX + SOAP - Mozilla Firefox 
File Edit View Go Bookmarks Tools Help 


@-®- 3 3249 a & http: //endirra.ro/ajax/verifica fisier2. html v| © Go 


x Disable” |a] Cookies” 5-5 CSS» G Formsy 3 Images” @ Information Miscellaneous” uv Dutlinev 


Numele fisierului : xmHfiles.pl 


Fisierul exista. [7] Redenumim? i 


Clear Inspect Options”! Console Debugger Inspector E 


GET http://localhost/ajax/verifica_exist.php?nume=xml-files.pl&_=  prototype.js (line 651) 
Response | Headers 


<?xml version="1.0" 2?><raspuns> 
<metoda>verificaExist</metoda> 
<rezultatel</rezultat> 
</raspuns> 


GET http://localhost/ajax/verifica_exist.php?nume=xml-files2.pl&_= prototype.js (line 651) 
GET http://localhost/ajax/verifica_exist.php?nume=xml-files.pl&_= prototype.js (line 651) 


O © c) Cenors / 0 wamings 


Figura 32. Trasarea apelurilor AJAX via extensia Firebug 
pentru navigatorul Firefox 


3.5. Invocarea directa, din JavaScript, a unui serviciu Web 


În continuare, ne propunem să invocăm direct un serviciu Web via metoda 
POST. Singura restricție este ca URl-ul folosit de obiectul XMLHZpRequest 
pentru trimiterea mesajului SOAP de cerere să aibă același domeniu cu cel al 
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serviciului (cu alte cuvinte, serviciul Web nu poate fi localizat decat pe masina pe 
care rezida si programul JavaScript ce recurge la AJAX). 

Ca exemplificare, presupunem că dorim să aflăm stocul unui sortiment de 
portocale, recurgând la metoda furnizeazaSortiment() implementată de serviciul 
Web prezentat în cadrul secțiunii 1.2. Programul JavaScript folosit la invocarea 
serviciului Web are codul-sursă de mai jos (se poate observa că structura 
generală a codului e similară celei prezentate mai sus, cu deosebirea că în acest 
caz vom iniţia o cerere POST spre server, adresa indicată fiind cea a serviciului 


Web): 


// adresa de apel al serviciului Web 

const URISERV = 
'http://localhost/sxml/oranges-server.php'; 

// adresa de bazá a serviciului Web 


const URIBSRV - 'http://localhost/sxml/'; 
// spatiul de nume al serviciului Web 
const URISPN - 'urn:portocale.info'; 


// generám mesajul SOAP de cerere 

// care va fi trimis spre server 

function genMesaj (numeDoc) { 

// construim 'de máná' mesajul SOAP de cerere 

var mesaj = "<soap:Envelope xmlns:xsi=\" 

+ "http://www.w3.0rg/2001/XMLSchema-instanceN" " 

+ "xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" " 
+ "xmlns:soap- 


\"http://schemas.xmlsoap.org/soap/envelope/\">\n" 
+ "<soap:Body>\n" 


+ "<furnizeazaCantit " + "xmlns=\"" + 
URISPN + "\">\n" 
"<sortiment>" + numeDoc + "</sortiment>\n" 


"</furnizeazaCantit>\n" 
"</soap:Body>\n" 

+ "</soap:Envelope>\n"; 
return mesaj; 


} 


+++ 


// invocăm metoda de validare 
function invoca (numeDoc) { 
var mesaj = genMesaj (numeDoc); 
try { 
if (window.XMLHttpRequest) { // doar pentru Firefox 
cerere = new XMLHttpRequest (); 
} 
// stabileşte funcția de tratare a stării încărcării 
cerere.onreadystatechange = trateazaCererea; 
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// trimitem cererea SOAP prin metoda POST 
cerere.open ("POST", URISERV, true); 
// stabilim tipul continutului 
cerere.setRequestHeader("Content-Type", "text/xml"); 
// stabilim valoarea cámpului SOAPAction 
cerere.setRequestHeader ("SOAPAction", 
URIBSRV + 'furnizeazaCantit'); 
cerere.send (mesaj); 
document.getElementById("txtCerere").value = mesaj; 
} 
catch (except) { 
alert ('A intervenit o exceptie: ' + except); 


// funcție care tratează starea conexiunii cu serverul 


function trateazaCererea () | 
// transferul s-a efectuat complet 
if (cerere.readyState == 4) | 
var raspuns = cerere.responseXML; 
// a apărut o eroare? 
if (cerere.status != 200) { 
alert("A apărut o eroare...\n" + 


cerere.statusText + 
cerere.getAllResponseHeaders()); 

return; 

} 

// furnizăm răspunsul primit de la server 

document .getElementByld("txtRaspuns") .value = 
raspuns.getElementsByTagName( 

'Body')[0].firstChild.firstChild.firstChild.data; 

return; 


—— 


Mesajul ce va fi transmis către server este „confecționat? manual, construind în 
acest mod plicul SOAP. In caz de eroare la întoarcere răspunsului, afisám si 
anteturile HTTP primite de la server via geZA//ResponseHeaders(). Valoarea stocului de 
portocale reprezintá in fapt elementul stránepot al elementului Body al ráspunsului 
SOAP (folosim proprietatea firstChild pusă la dispoziţie de modelul DOM). 

Formularul XHTML care preia de la utilizator numele unui sortiment de 
portocale si afişează răspunsul primit, inclusiv structura cererii SOAP efectuate, 
are următorul cod: 

<form> 


Numele sortimentului 
<input type="text" name="nume" 
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title="Introduceti un sortiment de portocale" 
onblur="javascript:invoca (this.value)" /> 
<br /> 
<!-- contine datele privitoare la cererea SOAP --> 
<textarea rows="10" cols="60" 
id="txtCerere"></textarea> 
<p>Stocul din sortimentul dorit este 
<input type="text" id="txtRaspuns"></input>.</p> 
</form> 


Un posibil rezultat este disponibil in figura de mai jos. 


©) Apel de servicii Web prin AJAX - Mozilla Firefox 
File Edit View Go Bookmarks Tools Help 


@-®- & en B Ca & B http://localhost/ajax-ws/portocale.html v| © Go 
3€ Disabler la] Cookies” 5-3 CSS- A) Forms” 3^ Images” (9 Information" Miscellaneous” ZA 


Numele sortimentului : albastre I 


<soap: Envelope 
xmlns:xsi-"http://www.w3.org/2001/XMLSchema-instance" 
xmlns:xsd-"http://www.w3.org/2001/XMLSchema" 
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/ "> 
<soap: Body> 

<furnizeazaCantit xmlns-"urn:portocale.ro"- 
<sortiment>albastre</sortiment> 

</furnizeazaCantit> 

</soap:Body> 

«/soap:Envelope- 


Stoeul din sortimentul dorit este ?4 


Clear Inspect Options”! Console Debugger Inspector | 


POST http://localhost/sxml/oranges-server.php ajax ws.js (line 45) 


Post Response | Headers 


Body><nsl: furnizeazaCantitResponse><return xsi:type-"xsd: int” /re 


| > 


25 a D errors / 0 warnings 


Figura 33. Rezultatul primit de la o metodă 
a unui serviciu Web invocat direct via XMLHttpRequest 
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3.6. Transferuri asincrone prin Atlas ASP.NET 


La finalul acestui subcapitol vom prezenta succint cadrul de lucru Azas ASP.NET, 
conceput special de Microsoft pentru realizarea de aplicaţii AJAX în contextul 
ASP.NET versiunea 2.0, dar putând fi folosit și în conjunctie cu alte tehno- 
logii de programare a aplicaţiilor Web, de exemplu PHP — a se vizita adresa 
http:/ /www.shankun.com/Atlas_Php_2.aspx. De asemenea, partea JavaScript faci- 
litand transferurile asincrone e compatibilă cu mai multe navigatoare, fără a 
trebui să recurgem în mod necesar la Internet Explorer. 

Pentru a utiliza Atlas, cunoştinţele pe care trebuie să le deţină programatorul 
în ceea ce privește tehnologia ASP.NET vor putea fi minimale. 

Pentru redarea datelor la nivelul clientului, se oferă un set de controale de 
interfaţă, în stilul ASP.NET, ale căror proprietăți pot fi stabilite fie declarativ 
(prin construcții XML), fie prin intermediul codului JavaScript. Aceste controale 
vor rula în fapt pe server, mediul având în responsabilitate generarea de marcaje 
(plus programe JavaScript), în funcţie de browser-ul folosit. Functionalitatea este 
încapsulată de un assembly numit Microsoft. Web. /Atlas.dll. 

O parte dintre controalele deja existente in ASP.NET sunt extinse pentru a 
oferi facilități suplimentare, în stilul AJAX. De asemenea, câmpurile de tip text 
pot avea atașat un mecanism de autocompletare a datelor (vezi exemplul de mai 
jos), iar conţinutul unor zone din cadrul documentului Web pot fi reimprospatate 
periodic (via UpdatePanel). Diverse elemente dintr-o pagina pot interactiona prin 
intermediul tehnicilor drag-and-drop, putând fi astfel mutate /ascunse dinamic. Mai 
mult decât atât, terțe componente pot îmbogăţi paleta controalelor existente; 
astfel, în Atlas pot fi incluse funcționalități noi. 

Accesul la datele de pe server se realizează prin apeluri asincrone de metode 
ale unor servicii Web locale (codul acestora trebuie să rezide pe aceeași mașină 
pe care există situl), conform modelului de securitate impus de JavaScript. 
Aceste servicii Web vor fi construite conform modalitátilor oferite de ASP.NET. 
Mediul are rolul de a realiza transferul efectiv al datelor — codificate conform 
convenției JSON între controalele interactive și server. 

Invocarea serviciilor externe se poate realiza prin așa-numita punte (bridge), 
cod inclus în fișiere cu extensia .ashx, ce va facilita dialogul cu servicii rulând pe 
alte calculatoare. Un astfel de exemplu de fapt l-am implementat mai sus, în 
secțiunea 3.3, dar printr-un intermediar scris în limbajul PHP. 

Alte detalii privitoare la arhitectura și modul de programare sunt disponibile 
în documentatiile si exemplele oferite pe situl Atlas. 

Drept exemplificare (o adaptare dupa una dintre soluţiile din tutorialele 
oficiale), ne propunem să punem utilizatorului la dispoziţie o facilitate de 
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sugerare a numelor unor sortimente de portocale, pe baza caracterelor deja 
testate de acesta. E vorba, așadar, de asocierea unui mecanism de autocompletare 
de date pentru un câmp textual al unui formular Web. Datele privitoare la 
sortimentele de portocale vor fi furnizate de un serviciu Web, care le va prelua 
dintr-un fișier text (desigur, scenarii mai complexe vor putea recurge la interogári 
SQL ori la preluarea informaţiilor din surse multiple). 

Atlas impune ca serviciul Web utilizat să aibă o unică metodă ce va fi invocată 
pe server, în manieră asincronă, la apariţia unui eveniment (apăsarea unui buton, 
introducerea unor caractere, la momente periodice de timp, la mișcarea cursorului 
mouse-ului etc.). Așadar, vom dezvolta un serviciu Web stocat de fișierul 
Portocale.asmx. Pentru aceasta, vom folosi şablonul „Azas” Web Site pentru Visual 
Web Developer Express (funcţionează si in Visual Studio .NET), pus la dispoziție 
în momentul instalării distribuţiei Atlas preluate de pe Web. Ulterior, vom atașa 
(bind) acest serviciu unui control az/oCozzplete dintr-o pagina ASP.NET. 

Codul-sursă este următorul — a se observa existența unei singure metode, 
denumită furnizeazaSortimente. 

<S@ WebService Language="C#" 

Class-"Portocale.Portocale" %> 
using System; 

using System.I0; 


using System.Collections; 
using System.Web.Services; 


namespace Portocale { 
WebService (Namespace = "urn:portocale.info") ] 


WebServiceBinding(ConformsTo = 
WsiProfiles.BasicProfilel 1)] 

public class Portocale 

System.Web.Services.WebService { 

// lista sortimentelor încărcate dintr-un fişier 

private static string[] sortimente = null; 


// furnizează o listă de sortimente ale căror nume 
// sunt prefixate de un sir dat 
[WebMethod] 
public String[] furnizeazaSortimente 
(string prefixText, int count) { 


// 'prefixText' si 'count' sunt denumiri 

// standard ai parametrilor de intrare trimisi 
// de controlul 'autoComplete' 

string prefix - prefixText; 

int lungMax - count; 

// încă nu există, încărcăm din fişier 
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if (sortimente == null) { 
String[] temp = File.ReadAllLines ( 
Server.MapPath("~/sortim portocale.txt")); 


// sortăm elementele pentru a putea realiza 


// căutarea binară 
Array. Sort (temp, 
new CaselnsensitiveComparer ()); 
sortimente = temp; 
) 


// realizám căutarea şi extragem maximum 'contor' 


// sortimente care se potrivesc prefixului 
// preluat de la client 


int index = Array.BinarySearch (sortimente, 
prefix, new CaseInsensitiveComparer()); 
if (index < 0) { 
index = ~index; 


} 
int potriviri; 
for (potriviri = 0; potriviri < lungMax && 
index + potriviri < sortimente.Length; 
potrivirir+) { 
// verificám dacă începe cu prefixul dat 
if (!sortimente[index + 
potriviri].StartsWith (prefix, 
StringComparison.CurrentCultureIgnoreCase)) ( 
break; 


} 
// copiem rezultatul obtinut 
String[] rezultat = new string[potriviri]; 
if (potriviri > 0) { 
Array.Copy(sortimente, index, rezultat, 
0, potriviri); 


} 
// transmitem spre client tabloul de siruri 
return rezultat; 


Desigur, putem invoca în mod explicit metoda definită mai sus. Primul 


parametru de intrare reprezintă prefixul, care trebuie să se potrivească fiecăruia 


dintre elementele listei de sortimente, iar al doilea specifică numărul maxim de 


sortimente ce vor fi întoarse. Datele vor fi sortate, iar căutarea va fi realizată prin 


metoda căutării binare, indiferent dacă literele sunt minuscule sau majuscule. 
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Un posibil rezultat, cu prefixText = "a" si count = 10, este documentul XML 
P 3 
dat în continuare: 


<?xml version="1.0" encoding-"utf-8"?» 

<ArrayOfString 
xmlns:xsi-"http://www.w3.org/2001/XMLSchema-instance" 
xmlns:xsd-"http://www.w3.org/2001/XMLSchema" 
xmlns="urn:portocale.info"> 


<string>Acre</string> 
<string>Albastre</string> 
<string>Albe</string> 


<string>Argintii</string> 

<string>Aspre</string> 

<string>Aurii</string> 
</ArrayOfString> 


Va trebui să scriem o pagina ASP.NET care să ofere un formular Web unde 
utilizatorul să fie îndemnat să furnizeze un nume de sortiment de portocale. La 
introducerea măcar a unui caracter, pe baza prefixului deja inserat în câmpul 
formularului, va trebui inițiat un transfer asincron care să invoce metoda 
furnizeaza Sortimente(). Rezultatul acesteia va fi afișat ca lista de sugestii într-un 
<div>, utilizatorul putând selecta unul dintre sortimentele apărute. 

Codul XHTML al formularului este următorul: 

«form id="formular" action="" runat="server"> 


<div>Introduceti un sortiment: 
«input id="sortiment" type="text" /></div> 


<!-- va includ lementele sugerate obtinute 
după invocarea asincronă a serviciului Web --> 
<div id="listaSortimente"></div> 
</form> 


Initial, marcatorul <div> cu id="histaSortimente” va fi ascuns, fiind completat 
de către Atlas la obţinerea listei de sortimente întoarse de serviciul Web. 
Elementului «put id="sortiment" type="text" /> va trebui să-i ataşăm com- 
portamentul de autocompletare, stabilind de asemenea și metoda serviciului Web 
ce va avea în responsabilitate returnarea listei de sugestii. 

Vom adopta metoda declarativă, la finalul paginii inserând liniile de mai jos: 

<script type="text/xml-script"> 

<page xmlns:script= 
"http://schemas.microsoft.com/xml-script/2005"> 
<components> 


<textBox id="sortiment"> 
<behaviors> 
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<!-- se defineste modul de 
autocompletare, prin apelul unei 
metode a unui serviciu Web --> 
<autoComplete 


completionList-"listaSortimente" 
serviceURL="Portocale.asmx" 


serviceMethod-"furnizeazaSortimente" 
minimumPrefixLength="1" 
completionSetCount="15" 
completionInterval-"500" /> 
</behaviors> 
</textBox> 
</components> 
</page> 
</script> 


Se poate deduce ușor faptul cá pentru controlul de tip text cu ¿d=" sortiment" 
se asociază un marcator XHTML ce va conţine rezultatul metodei serviciului 
Web invocat, unde lungimea prefixului trebuie să fie minimum 1 (această valoare 
o va avea parametrul prefixText de mai sus), mulțimea elementelor sugerate va fi 
de maxim 15 (parametrul count va avea asociată această valoare) si intervalul de 
completare va fi de 500 de milisecunde. 

Maniera efectivă de transfer asincron al datelor între client și server este 
realizată în mod transparent de către Atlas. În captura-ecran de mai jos pot fi 
urmărite informaţiile despre sortimentele sugerate la introducerea literei „A” de 
către utilizator, plus apelurile AJAX dintre pagină si serviciul Web. Puteţi remarca 
faptul că datele vehiculate sunt codificate în stilul JSON (în cazul nostru, 
parametrii de intrare sunt perechi nume-valoare incluse într-o listă, iar rezultatul 
obţinut reprezintă un tablou de șiruri de caractere). 

Din moment ce vom selecta unul dintre sortimente, acesta va fi automat 
introdus ca text în cadrul câmpului formularului Web. 

Dorim să adăugăm si un buton etichetat „Alege”, la apăsarea căruia să fie 
invocat — tot în manieră asincronă — un alt serviciu Web, care să realizeze o 
anumită acţiune (in acest caz, va întoarce un șir de caractere ce va fi redat fără 
a se realiza reîncărcarea întregului document). Astfel, putem reîmprospăta 
diverse zone ale paginii, fie în mod explicit, fie periodic sau în funcţie de alti 
factori. 
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File Edit View Go Bookmarks Tools Help 


-P~ 8 A af & E http: /localhost/dojo-0. 3.1 -kitchen_sink/demos/demoE ngine. html a 
2€ Disable” la] Cookies” 5.) CSS» (©) Forms 3^ Images" (9 Information" Miscellaneous” Z Outliner Resizer 


Mail 
Dojo 


Demos _ i o | source demo 
Simple Mail Application demonstration 


| 4p Get Mal | | E New Message | 


-H4 ip Sender 
TE OX 
2SenMai | Adam Arlen 


gi Deleted. | Bob Baxter 
» Saved Mail | Carrey Crown 


David Davis Transport type | IMAP ¥ 
Server: localhost 


This is a simple a bjo — 
widgets: 


"o— 
+ split pane zl 


+ floating päre — 
+ layout pane 

* tree 

+ button 

+ TabContainer 

+ editor 


Sending/Receiving | Composition | 


Click on the messages in the Inbox, or try to edit the options — 
or create a new message. There's no server running, so the 
app is just a facade and it doesn't really do anything. 


Done 05 9 
Figura 34. Folosirea unui control de tip autoComplete în Atlas ASP.NET 


Pentru aceasta, va trebui să mai concepem un serviciu Web — CantitPortocale.asmx — 
al cărui cod C£ simplu e dat în continuare (omitem construcțiile neesentiale): 


// afişează sortimentul preluat de la client 
[WebMethod] 
public String listeazaSortiment (string query) { 

// preluăm parametrul 

string sortiment = Server.HtmlEncode (query); 

// dacă nu există sau e vid, 

// întoarcem un mesaj de avertizare 

if (!String.IsNullOrEmpty(sortiment)) { 

return String.Format ("Ati ales sortimentul {0}!", 
sortiment); 
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else { 
return "Parametrul de intrare primit e vid..."; 


Este disponibilă o singură metodă care preia valoarea unui control ASP.NET 
via obiectul Server şi întoarce un șir de caractere. Desigur, mai util pentru 
utilizator ar fi fost să obţină stocul de portocale din respectivul sortiment; acesta 
este însă un exercițiu ușor de implementat de către cititor. 

La formularul descris mai sus, vom adăuga următoarele: 


<!-- buton ce invocă un alt serviciu --> 
<input id="alege" type="button" value="Alege" 
onclick-"javascript:Invoca()" /> 


<div id="rezultat"></div> 


După cum se remarcă, la apăsarea butonului va fi invocată metoda 
listeaxaSortiment(), de data aceasta via JavaScript. Rezultatul va fi conţinut de un 
element <div>. Funcţia Invoca() are liniile de mai jos: 

function Invoca() { 


// preluăm sortimentul 
var sortim = document.getElementById("sortiment"); 


// invocám metoda 
Portocale.CantitPortocale.listeazaSortiment 
(sortim.value, TrateazaTransfer) ; 
} 
function TrateazaTransfer (rezultat) { 
// inserám rezultatul in <div> 
document.getElementById("rezultat").innerHTML = 


rezultat; 


Cu getElementByld() oferită de DOM preluám numele sortimentului și invocám 
metoda serviciului Web — se folosește forma SpatiuDeNume.ServiciuW eb.Metoda(). 
Primul argument este tocmai parametrul de intrare al metodei, iar al doilea 
desemneaza functia JavaScript ce va fi apelata la terminarea transferului. Nu 
facem decât să inserăm in marcatorul <div> rezultatul obţinut de la server. 

Ca mediul Atlas să poată realiza managementul transferului de date, în antetul 
paginii trebuie să introducem o referință la serviciul Web invocat: 

<!-- face referință la serviciul Web invocat 


prin JavaScript în stilul AJAX --> 
<atlas:ScriptManager runat="server" id="Atlas"> 


<services> 
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<atlas:servicereferenc 


path="~/CantitPortocale.asmx" 
type-"text/javascript" /> 
</services> 


</atlas:ScriptManager> 


La rulare, vom obţine un rezultat precum cel din figura 35. 


z 
©) Sortimente de portocale - Mozilla Firefox 


File Edit View Go Bookmarks Tools Help 


@-®- e e A | LA |] http://localhost:1320/Portocale/default.asp Y 
x Disable” [a] Cookies” 5.5 CSS ©) Formsy 3^ Images” (9 Information" Miscell 


Introduceti un sortiment: Albastre 


Ati ales sortimentul Albastrel 


POST WebResource.axd?d... (line 832) 


http://lacalhost: ien SIE LOIR SAT RTT 


Post Response | Headers 


"Ati ales sortimentul Albastre!” — 
wv 


Figura 35. Actualizarea continutului fara reincarcarea întregului document 


Alte abordări AJAX pentru .NET sunt ALAX. NET, MagicAjax. NET, JSON.NET 
si xap4net. 

Cele descrise mai sus pot fi realizate si in Java, prin intermediul framework-ului 
DWR (Direct Web Remoting) sau via jMaki, SWATO ori Taconite. De asemenea, 
Google pune la dispoziție GWT (Google Web Toolkit), scopul acestui instrument 
fiind cel de a oferi suport pentru scrierea in Java de aplicatii orientate spre 
AJAX. Pentru PHP, se poate recurge la pachetul HTML::AJAX, disponibil in 
colecția PEAR, iar programatorii Perl pot utiliza extensiile Mason pentru AJAX. 

Alte cadre de lucru ofera suport pentru AJAX in mai multe limbaje de 
programare, de menţionat fiind CPAINT (Cross-Platform Asynchronous Interface 
Toolkit), JSON-RPC si Sajax. Nu trebuie uitat nici Raby on Rails, unul dintre 
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framework-atile de dezvoltare a aplicaţiilor Web pe partea de server foarte 
cunoscute în acest moment, cu suport pentru AJAX. 

În funcţie de preferinţe, de cerinţele problemei, de avantaje și/sau de 
platformă, dezvoltatorul poate adopta una dintre soluţiile disponibile. 
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Capitolul 7 


Retrospectiva si perspective 


„Realitatea trebuie înțeleasă numai prin spargerea 
ei în parti cat mai mici.” 
(René Descartes) 


1. Procesul de dezvoltare a serviciilor Web 


Recapituland cele prezentate in capitolele anterioare, procesul de dezvoltare a 
serviciilor Web implica trei categorii de activităţi (a se urmări și figura 1): 


— oferirea de servicii, ceea ce presupune dezvoltarea propriu-zisă a serviciilor puse 
la dispoziţie într-un mediu de tip enterprise, plus expunerea unei documentatii 
(descrieri) privitoare la interfaţa serviciilor; implementarea poate fi realizată 
pe baza limbajelor de programare, cadrelor de lucru și platformelor actuale, 
iar descrierile sunt specificate via WSDL și alte metode adiționale; 

— organizarea (catalogarea) serviciilor Web conform unor criterii vizând tipul de 
afacere modelată, localizarea ofertantului, industria considerată etc; în acest 
sens, una dintre inițiativele majore este reprezentată de UDDI; prin inter- 
mediul UDDI, un ofertant de servicii poate fi ușor contactat de către posibilii 
solicitanti (clienti); 

— solicitarea de servicii fie direct, atunci cand interfaţa acestora este deja cunoscută, 
fie indirect via UDDI; solicitantul isi va proiecta aplicatia doritá si va invoca 
functionalitatile serviciilor conform documentului WSDL asociat fiecárui 
serviciu in parte ori apelând la o interfață de programare (API) specifică. 
Schimbul de date între serviciu și client se va realiza — în mod uzual — prin 
intermediul SOAP, folosindu-se un protocol de transport oferit de Internet 
(cel mai frecvent, se recurge la HTTP). O alternativă la SOAP este dată de 
modelul REST, în care mesajele interschimbate, marcate de asemenea în 
XML, sunt transferate direct prin HTTP, fără a fi incapsulate în „plicuri”. 
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Figura 1. Activitățile desfășurate in dezvoltarea serviciilor Web 


Acest proces are loc în cadrul unui mediu orientat spre servicii, respectandu-se 
principiile arhitecturale SOA (Service-Oriented Architecture) pe care le-am prezentat 
în cadrul primului capitol al acestei lucrări. 

O aplicaţie Web proiectată pe baza SOA poate fi compusă din diverse straturi 
funcționale, conform celor ilustrate de figura 2. 


Client Prezentare Componente Back-end 


Figura 2. Structura aplicațiilor software axate pe SOA 
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2. Alte initiative vizand serviciile Web 


2.1. Privire de ansamblu 


În ceea ce priveşte dezvoltarea de aplicaţii SOA în general si de servicii Web în 

particular, tehnologiile SOAP, WSDL și UDDI nu sunt singulare, actualmente 

fiind disponibile o serie de specificaţii și iniţiative adiţionale privitoare la: 

. modul de adresare: WS-Addressing, 

. inspecţie si descoperire: WS-Inspection, WS-Discovery; 

„ mesagerie: WS-ReliableMessaging, WS Attachments, WS-Routing etc.; 

„ securitate si autorizare: WS-Security, WS-Trast, WS-Policy si altele; 

. procesarea tranzacţiilor: WS-Coordination, WS-Transaction; 

. relaţia cu interfata-utilizator: WSRP (Web Services for Remote Portlets), WSIA 
(Web Services for Interactive Applications); 

7. asigurarea inter-operabilitatii si fluxului de activități (workflow): BPEL (Business 
Process Execution Language) și WS-Choreography. 
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Figura 3. Nivelurile de specificatii adiționale privitoare la serviciile Web 
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Trebuie, de asemenea, menţionată existenţa unei suite de specificații comple- 
mentare, concurente, care se intitulează ebXML si care a fost în vogă în perioada 
2002-2005. Aceste specificaţii au fost date ulterior spre standardizare organizației 
OASIS, semnatara multor documente privitoare la diverse aspecte legate de 
SOA și serviciile Web. 

Vom descrie în continuare o parte dintre direcţiile de evoluţie a serviciilor 
Web, cititorii interesați putând aprofunda aceste aspecte prin consultarea resur- 
selor bibliografice disponibile. 


2.2. Adresarea serviciilor prin WS-Addressing 


Iniţiativa WS-Addressing specifică modul de utilizare a unor mecanisme — inde- 
pendente de protocolul de transport folosit — destinate adresării serviciilor și 
mesajelor. Specificatia, propusă de IBM, definește elementele XML menite a 
identifica punctele terminale ale serviciilor Web şi maniera de asigurare a 
securității comunicaţiilor dintre aceste puncte terminale. Sistemele de mesagerie 
(messaging systems) pot realiza transportul mesajelor în cadrul unor reţele de 
comunicaţii — uzual, folosite în mediul enterprise — care pot include noduri de 
procesare a datelor, precum firewall-uri sau porti (gateways), indiferent de pro- 
tocoalele disponibile la nivel scăzut. 

Din perspectiva WS-Addressing, modelul de descriere a serviciilor Web (Ze., 
WSDL) este extins prin introducerea conceptului de referință la punctele 
terminale (endpoint reference). Astfel, maniera în care se specifică adresa unui 
serviciu Web este mai fină, deoarece nu implică doar un URI (de exemplu, pot 
fi specificate meta-date suplimentare și adresele mai multor documente WSDL). 

Mesajele vehiculate pot fi identificate și corelate prin anteturile MessageID si 
RelatesTo, ceea ce deschide perspective interesante privind tranzacţiile și fluxurile 
de date. Sunt introduse și atribute precum To, From, ReplyTo şi FaultTo, care pot 
fi folosite de către agenții implicaţi in comunicare pentru a procesa un mesaj si 
răspunsurile aferente la acesta. 


2.3. Descoperirea serviciilor 


În capitolul 5 am discutat deja despre maniera de descopetire a serviciilor fie în 
manieră centralizată via UDDI, fie descentralizat prin WS-Inspection. 

In cadrul acestei sectiuni, vom prezenta succint modul de descoperire 
dinamică, specificat de WS-Discovery (propunere a corporatiei Microsoft). In loc 
de a se stoca informaţiile privitoare la servicii într-un catalog central, modelul 
WS-Discovery adoptă strategia folosită si de sistemele wireless: un serviciu Web își 
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poate anunţa — via mesaje multicast — prezenţa, atunci cand este ,,atasat” infra- 


structurii Internet. Un procedeu similar are loc atunci când serviciul ,,paraseste” 


rețeaua. Reţeaua este una constituită ad hoc, compusă din entități interesate de 


serviciul respectiv (Ze., clienti care intenționează să invoce anumite operaţii). 


Limitarea 


traficului de mesaje poate avea loc prin constituirea unui aga-numit 


proxy de descoperire (discovery proxy) care este implementat tot ca un serviciu 


Web. 


În afară de mesajele de tip Hello (anunţ al prezenţei unui serviciu) si Bye 


(„plecarea” serviciului), sunt specificate si următoarele două operaţii: 


— Probe — încearcă să detecteze un anumit serviciu ori mulțime de servicii prin 


transm 


iterea unui mesaj (multicast) către un grup de calculatoare, răspunsul 


fiind expediat direct solicitantului. Dacă rețeaua posedă un proxy de desco- 


perire, 


— Resolve 


atunci metoda Probe va fi executata direct de catre acesta; 
— intenționează să „rezolve” un serviciu, căutarea efectuându-se dupa 


numele acestuia, trimitandu-se un mesaj în întreaga reţea. Serviciul care se 


potriveşte cu numele dat, va răspunde solicitantului. Acest proces este similar 
celui folosit de protocolul ARP (Address Resolution Protocol). 


Un exemplu de mesaj SOAP care încapsulează o cerere Probe este furnizat 


mai jos (pentru localizare se folosește protocolul LDAP — Lightweight Directory 
„Access Protocol): 


<env:Envelope> 
<env:Header> 


<wsa:Action> 


http://schemas.xmlsoap.org/ws/2004/10/discovery/Probe 


</wsa:Action> 
<wsa:To> 


urn: schemas-xmlsoap-org:ws:2004:10:discovery 


</wsa:To> 


</env:Header> 
<env:Body> 


"http 


<wsd: Probe> 


<!-- dorim asocierea serviciului Web --> 
<wsd:Types>sfa:Binder</wsd:Types> 
<!-- ...din cadrul domeniului info.uaic.ro --> 


<wsd:Scope MatchBy= 
://schemas.xmlsoap.org/ws/2004/10/discovery/ldap"> 


ldap: ///ou=info, o=uaic, c=ro 


</wsd:Scope> 
</wsd: Probe> 


</env:Body> 


</env 


:Envelope> 
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Pe baza acestei initiative si a altora înrudite (precum WS-Eventing), poate fi 
constituită o infrastructură de descoperire dinamică sofisticată, oferind suport 
pentru managementul serviciilor Web. Suplimentar, în conjunctie cu UPnP 
(Universal Plug and Play), serviciile Web pot rula pe diverse tipuri de dispozitive, 
fiind regăsite în mod dinamic. De altfel, există deja disponibil un ghid privitor 
la implementarea serviciilor Web pe calculatoare cu resurse limitate, precizându-se 
un profil minimal denumit WS-DP (Device Profile for Web Services). 


2.4. Coordonarea serviciilor Web 


Deoarece serviciile Web pot fi incluse într-o arhitectură distribuită complexă, se 
pune problema colaborării între diversele entități software implicate pentru a 
rezolva o anumită problemă specifică (de exemplu, oferirea unei soluţii de 
petrecere a vacanței de către un sit de tip e-travel). 

Orice colaborare presupune acceptarea unui contract (agreement). Pentru 
sistemele bazate pe transfer de mesaje — cazul serviciilor Web —, un contract, în 
forma cea mai simplă, presupune respectarea unui format comun de date (e.g., 
specificat printr-o schemă XML), a unui stil de transmitere a mesajelor (unidirec- 
tional, cerere/răspuns, notificare etc.) si a unei modalități de descoperire a 
participanţilor la realizarea problemei. Aceasta implica o activitate de coordonare. 
Cu cât interacțiunile dintre servicii sunt mai sofisticate, cu atât procesul de 
coordonare devine mai dificil. Modul de coordonare poate fi unul centralizat, 
implicând existenţa unui coordonator explicit cu rol de „șef”, sau nu. 


Initiativa N S-Reliable Messaging 


Unul dintre aspecte importante este cel referitor la realizarea de comunicaţii 
fiabile. Necesitatea existenţei unui mecanism de asigurare a fiabilitátii transferului 
de date provine și din următoarele presupuneri greșite pe care le au dezvoltatorii 
de aplicaţii privind un sistem distribuit (formulate de Peter Deutsch la începutul 
anilor 790 ai secolului trecut): 


reţeaua este fiabilă (re/ab/e); 

latenta datelor este nulă; 

lăţimea de bandă e infinită; 

reţeaua este sigură (secure); 

topologia rămâne neschimbată; 

există un singur administrator; 

costul transportului de date este zero; 


DOSS. UU spas poss 


rețeaua este omogenă. 
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În contextul serviciilor Web (exemple tipice de componente ale unui sistem 
distribuit), se poate folosi specificatia W'/$-ReZableMessaging, redactată de către 
IBM. Scopul acestui document este cel de a stabili un protocol care sa permita 
livrarea în siguranță a mesajelor, chiar si in prezența unor erori (failures) ale 
componentelor software, ale platformei utilizate ori ale reţelei. 

Pe baza unor informaţii suplimentare atașate în antetul mesajelor SOAP, 
datele pot fi grupate în secvenţe. Secvența de mesaje este stabilită de către 
expeditor, iar ordinea trebuie să fie respectată atunci când secvenţa ajunge la 
destinatar (nodul z/ateReceiver). Partenerii dialogului trebuie să accepte con- 
tractul privitor la secvența de mesaje vehiculate. Iniţierea unei secvenţe are loc 
prin operaţia CreateSeguence, iar partenerul dialogului își va arăta disponibilitatea 
printr-un răspuns CreateSequenceResponse. Această abordare nu necesită prezența 
unui coordonator explicit. Fiabilitatea este asigurată prin confirmarea fiecărui 
mesaj in parte via elementele Sequence, SequenceFault, SequenceAcknowledgement şi 
AckReguested. 

Liniile de mai jos reprezintă confirmarea mesajelor de la 1 la 7 si de la 9 la 
10 dintr-o secvenţă (mesajul 8 nu a fost confirmat încă): 


<env:Envelope 
xmlns:env-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:rm- 
"http://schemas.xmlsoap.org/ws/2005/02/rm"» 
<env:Header> 


«rm:SequenceAcknowledgment» 
<rm:Identifier> 


</rm:Identifier> 
<rm:AcknowledgmentRange Upper="7" Lower="1" /> 
<rm:AcknowledgmentRange Upper="10" Lower="9" /> 
</ rm: SequenceAcknowledgment> 
</env:Header> 
<env:Body> 


</env:Body> 
</env:Envelope> 


Protocolul este neutru in ceea ce priveste infrastructura de transport folosita 
efectiv. Transferul datelor trebuie sa respecte diverse preconditii (una fiind, de 
exemplu, ordinea mesajelor vehiculate). La nivelul HTTP, o iniţiativă este HTTPR 
(Reliable HTTP). 
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Coordonarea explicită a serviciilor Web 


O franzactie reprezintă un mecanism care asigură cá toti participanţii din cadrul 
unei aplicaţii vor obţine același rezultat, conform unui contract (agreement) mutual 
agreat. În mod tradiţional, o tranzacţie care are proprietăţile de mai jos (întâlnite 
sub denumirea de ACID — Avomicity, Consistency, Isolation, Durability) se numeşte 


atomic. 


— atomicitate — tranzactia se incheie cu succes dacá toate actiunile pe care 
aplicatia trebuie sa se realizeze in cadrul tranzactiei au putut avea loc; in caz 
contrat, tranzacţia eșuează si nici una dintre acţiuni nu va fi executată 
(insuccesul unei singure operatii va cauza invalidarea executiei tuturor actiu- 
nilor din cadrul tranzacţiei); 

— consistență — tranzacţiile vor produce întotdeauna rezultate consistente si vor 
păstra transformările de stare ale aplicaţiei la terminare; 

— izolare — stările intermediare ce apar în timpul desfășurării unei tranzacţii vor 
fi invizibile pentru alte tranzacţii; tranzacțiile apar ca fiind executate secvențial, 
chiar dacă sunt realizate în manieră concurentă; aceasta se poate realiza prin 
„încuierea” (/ock&ing) resurselor pe durata desfășurării tranzacţiei, astfel încât 
nici o altă tranzacţie să nu aibă posibilitatea folosirii lor, evitandu-se posibilele 
conflicte de acces; 

— durabilitate — după ce o tranzacţie se finalizează cu succes, schimbările 
survenite pot fi gestionate până la apariția unei erori catastrofale. 


Un exemplu de tranzacţie este cel referitor la oferta unui serviciu de turism, 
care implică existenţa unui agent (¢rave/ agent) având rolul de a rezerva bilete la 
avion (sau tren, autocar etc.), de a închiria diverse mijloace de transport la 
destinaţie, de a rezerva o camera la un hotel și, eventual, de a pune la dispoziţie 
si alte servicii (eg., angajarea unui ghid ori programarea unui tur de vizitare a 
localităţii respective). Esuarea uneia dintre activităţile ce compun tranzacţia (de 
exemplu, imposibilitatea găsirii unei soluţii de cazare) conduce la abandonarea 
întregului serviciu. 

În contextul serviciilor Web, compunerea unuia sau mai multor servicii 
conduce la constituirea aplicaţiilor tranzactionale ale căror componente sunt slab 
conectate si distribuite pe sisteme eterogene și independente. Astfel, unele 
proprietăţi ale tranzacţiilor atomice pot fi aplicate, în diverse situaţii, mai puţin 
strict. 

Intervine necesitatea existenţei unui mecanism flexibil de coordonare, care să 
permită colaborări, fluxuri de lucru (workflow), procesare în timp real etc. In 
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unele situatii, aceasta coordonare trebuie realizata explicit, interactiunea avand 
loc uzual între doi participanţi (desigur, putem generaliza la un număr oarecare 
de parti componente). Coordonarea se poate desfășura spontan — asa cum se 
întâmplă la un schimb sincronizat de mesaje de tip cerere/răspuns (invocarea 
unui serviciu și obținerea rezultatului) — sau printr-un coordonator. Pentru 
această a doua situaţie, a fost propusă specificatia WS-Coordination, având drept 
initiatoare companiile BEA, IBM si Microsoft. Se precizează un cadru de lucru 
extensibil care să ofere protocoale pentru coordonarea acțiunilor desfășurate de 
aplicaţiile distribuite. 

Specificatia introduce conceptul de context de coordonare (Coordination Context), 
care apare într-un bloc antet SOAP și care identifică unic o activitate ce trebuie 
desfășurată în comun. Pentru a initia o activitate executată de mai multe servicii, 
un serviciu Web va expedia un context de coordonare la serviciile vizate. 
Contextul va conţine informaţiile necesare pentru ca o entitate să decidă dacă 
dorește să ia parte la activitatea preconizată sau să refuze propunerea. Aceste 
informaţii depind de specificul activităţii. Mulțimea tipurilor de coordonare este 
deschisă, noile tipuri putând fi definite de o anumită implementare, atât timp cât 
toti participanţii le cunosc si consimt să le folosească. Comportamentul unui 
anumit serviciu este expus prin intermediul unui proces de înregistrare (registration) 
transmis coordonatorului. Pe baza înregistrării, pentru a rezolva o problemă dată 
poate fi invocat un întreg grup de servicii. 

De asemenea, serviciul coordonator are astfel posibilitatea să orchestreze 
serviciile Web (vezi secţiunea 2.9) și/sau să realizeze tranzacții. 

Interacțiunile de tip B2B (Business-to-Business) se pot desfăşura conform 
următoarelor protocoale definite de WS-Coordination: 


— tranzactie atomică (atomic transaction) — corespunde tranzacţiilor cu proprietăţile 
ACID menţionate mai sus si e specificată de WS-AtomicTransaction (vezi infra); 

— intra-enterprise — în cadrul aceleași organizaţii (domeniu), tranzacţiile au loc 
atomic de-a lungul variatelor aplicaţiilor interne; 

— inter-enterprise — reprezintă activitatea de bază desfășurată in context B2B, 
necesitând un grad mare de inter-operabilitate cu sistemele tranzactionale 
existente; 

— activitate de afaceri (business activity) — necesită o flexibilitate sporită a com- 
ponentelor sistemului fata de cerinţele stricte ale tranzacţiilor atomice (ACID). 
Interacțiunile pot avea loc timp îndelungat, iar serviciile sunt de cele mai 
multe ori slab conectate. Restrictiile privind atomicitatea și izolarea sunt 
relaxate. Acest model are legătură și cu maniera de realizare a proceselor de 
afaceri. 
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Realizarea tranzactiilor atomice 


Pentru specificarea tranzacţiilor atomice în contextul serviciilor Web, există 
disponibilă inițiativa WS-AtomicT ransaction. 

Iniţierea unei procesări de date (văzută ca o unitate atomică) are loc prin 
protocolul numit Completion. Un serviciu Web înregistrat pentru Completion are 
abilitatea de a instiinta coordonatorul atunci când inițiază o tranzacţie. De 
asemenea, acest protocol definește forma mesajelor ce pot fi folosite pentru a 
comunica rezultatul final al tranzacţiei iniţiatorului acesteia. 

Specificatia WS-AtomicT ransaction pune, de asemenea, la dispoziţie si protocolul 
numit Two-Phase Commit. loti participanţii înregistraţi trebuie să ia în comun 
decizia de a duce până la capăt (commit) o tranzacţie oti de a o abandona. 
Suplimentar, protocolul asigură faptul cá toti participanţii vor fi anunțați asupra 
rezultatului final. Sunt definite două variante ale protocolului: una volatilă și 
cealaltă durabilă. Protocolul volatil poate fi folosit de participanţi care deţin 
resurse volatile (e.g., cache), pe când cel durabil este destinat participanţilor având 
resurse considerate durabile (precum baze de date ori fișiere). 

Inter-operabilitatea este asigurată graţie folosirii protocolului SOAP. Politicile 
de efectuare a tranzacţiilor pot fi specificate prin intermediul W'S-Po/0y, iar 
aspectele legate de securitate sunt lăsate în seama propunerilor WS-Security si 
WS-Trast, pe care le vom prezenta mai jos. 

În conjunctie cu WS-BusinessActivity, pot fi implementate tranzacții care se 
desfășoară timp îndelungat (de exemplu, procesări complexe). 


Managementul cozilor de mesaje 


Deseori, mai ales în contextul transmiterii asincrone de mesaje, apare necesitatea 
utilizării cozilor (gueues) de tranzacții durabile. Comunicarea între entitățile 
participante are loc via cozi de mesaje (MQ — Message Queue). Aplicația care 
expediază datele le plasează — în maniera unei tranzacţii atomice (via 
WS-AtomicTransaction) — într-o coadă. Mesajul se consideră stocat cu succes in 
cadrul cozii doar dacă nu apare nici o excepţie de procesare (adică tranzacţia nu 
a eșuat). 

Subsistemul de management al cozilor va avea misiunea de livrare a mesajului 
emis de expeditor către destinatarul final. Acest proces poate fi desfășurat la un 
moment de timp diferit de cel al includerii mesajului în coadă. De asemenea, 
locaţia cozii de mesaje nu trebuie să coincidă cu cea a expeditorului ori a 
destinatarului. 
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Aplicatia care preia mesajul din cadrul cozii va realiza acest lucru printr-o 
tranzacție atomică, astfel încât datele vor fi livrate cu succes (și eliminate din 
coadă) doar în cazul în care nu apar excepţii de procesare la nivelul destinatarului. 


2.5. Accesarea resurselor serviciilor Web 


În unele situaţii, schimbul de mesaje între un serviciu și clienţii săi presupune un 
dialog mai complex decât o simplă pereche cerere-răspuns. De exemplu, pot 
apărea cazuri în care este nevoie de specificarea transferului unor interogări de 
baze de date, fluxuri de informaţii multimedia, liste de enumerare a unor valori etc. 

Deoarece HTTP este un protocol lipsit de stări (s/2/e/ess), nu se poate cunoaște 
dacă diverse cereri succesive provin de la același client. Apare necesitatea de a 
prezerva anumite date de-a lungul mai multor accesări înrudite ale unui serviciu 
Web. Acest aspect se realizează prin intermediul sesiunilor, exact ca si în cazul 
aplicaţiilor Web convenţionale. 

Pentru enumerarea datelor via mesaje succesive, se va stabili o sesiune prin 
operaţia Enumerate, precizată de specificatia WS-Enumeration. De asemenea, acest 
document definește si modul de accesare a secventelor de date. Sesiunea este 
declarată la nivel abstract prin intermediul unui context de enumerare (enumeration 
context), cate reprezintă un cursor logic ce parcurge o secvență de informaţii 
oferite de o anumită sursă de date (sistem de baze de date relationale, server de 
baze de date native XML etc.). Aceste date, reprezentate via XML Infoset, vor fi 
livrate printr-o succesiune de mesaje SOAP. 

Cea mai simplă operaţie este P7/// care permite ca o sursă de date, într-un 
anumit context de enumerare, să producă o secvenţă de elemente XML (repre- 
zentate intern prin Ivfosef) încapsulate în corpul unui mesaj SOAP. Fiecare 
operație Pz//ce va urma va întoarce următoarele N elemente din cadrul secventei. 

Conform WS-Enumeration, se pun la dispoziţie si operațiile: 


— Renew — utilizată să extindă validitatea unui context de enumerare (reim- 
prospătează o sesiune); 

— GetStatus — oferă informaţii privitoare la un context de enumerare; 

— Release — eliberează resursele deţinute în cadrul unei sesiuni și elimină un 
context de enumerare. 


În caz de eroare (enumerarea s-a terminat neprevăzut), sursa de date va 
transmite un mesaj de tip EnumerationEnd. 

În conjunctie cu specificatia prezentată mai sus, poate fi folosită WS-Transfer, 
care are în responsabilitate definirea operaţiilor de bază privitoare la mana- 
gementul entităţilor de date vehiculate via servicii Web. 


284 SERVICII WEB 


WS-Transfer defineşte resursa ca fiind orice entitate adresabilă de o referinţă a 
unui punct terminal, entitate ce oferă o reprezentare XML a datelor. De 
asemenea, se introduce conceptul de fabrică (factory): un serviciu Web care poate 
„construi” o resursă având la dispoziţie reprezentarea ei XML. 

Sunt specificate operaţii privitoare la crearea, actualizarea, obținerea si ster- 
gerea resurselor (operaţii de tip CRUD — Create, Retrieve, Update, Delete). Crearea 
unei resurse este realizată de o fabrică, aceasta constituind resursa dorită si 
stabilind reprezentarea sa inițială. 

Ilustrăm in continuare modalitatea de creare a unei resurse privitoare la 
achiziţia unui sortiment de portocale: 


<env:Envelope> 

<env:Header> 
<!-- actiunea realizata --> 
<wsa:Action> 
http://schemas.xmlsoap.org/ws/2004/09/transfer/Create 
</wsa:Action> 


</env:Header> 
<env:Body> 
<p:portocale p:xmlns-"urn:portocale.info"» 
<p:achizitii> 
<p:tip>Portocale greceşti fără coajă</p:tip> 
<p:cod>P10-01-GR</p:cod> 
<p:cantit p:um="kg">3374</p:cantit> 
«/p:achizitii» 
</p:portocale> 
</env:Body> 
</env:Envelope> 


Dacă transferul de date se desfășoară in mod asincron, posibilele evenimente, 
ce pot surveni pot fi tratate prin intermediul mecanismului oferit de WS-Eventing. 
Un serviciu Web (numit subscriber) îşi precizează lista evenimentelor asupra 
cărora este interesat (si va fi notificat), evenimente generate de alt serviciu Web 
(denumit event source). Sunt precizate si operaţiile ce pot fi efectuate asupra 
evenimentelor sau grupurilor de evenimente. De asemenea, pot exista și entități 
de tip broker de evenimente cu rolul de a agrega ori redistribui notificări de 
evenimente. 

La finalul acestei secţiuni, trebuie să amintim și inițiativa WS-Management, care 
oferă diverse facilități referitoare la managementul serviciilor Web (inclusiv al 
resurselor transferate sau al evenimentelor de comunicare) pe baza protocolului 


SOAP, 
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2.6. Accesarea meta-datelor asociate serviciilor 


Pentru a facilita dezvoltarea si exploatarea serviciilor Web, fiecărui astfel de 
serviciu 1 se pot asocia, prin intermediul meta-datelor, diverse descrieri adiționale. 
Meta-datele sunt specificate într-un format ușor de procesat de către calculator, 
oferind suport pentru automatizarea activităților de implementare sau de regăsire 
a serviciilor. De asemenea, meta-datele pot fi de folos pentru creșterea gradului 
de inter-operabilitate a serviciilor. 

Meta-datele descriu maniera schimbului de mesaje, functionalitatile și cerințele 
(requirements) asociate unui serviciu. Aceste cerințe formează așa-numita politică 
(policy) de acces. Formatele de date și sabloanele de interschimb de mesaje sunt 
specificate în cadrul documentelor WSDL, după cum am văzut în capitolul 2. 
Politicile de acces sunt subiectul specificatiei WS-Polcy. 

Întreg setul de meta-date formează așa-numitul contract asociat serviciului, 
contract exprimat prin construcții (elemente) XML Schema, WSDL si WS-Policy 
(a se vedea și figura 4). 


WSDL 
modele de 
interschimb 


de mesaje 


Contract 


Figura 4. Categoriile de meta-date care formează contractul asociat unui serviciu Web 


Documentele WSDL nu sunt capabile să ofere posibilelor entități de calcul 
sau dezvoltatorilor de aplicaţii informaţii privitoare la diverse caracteristici 
operaţionale, de securitate sau referitoare la exploatarea serviciilor Web. De 
exemplu, ar fi util de cunoscut dacă accesarea serviciului se realizează pe baza 
unui sistem de autentificare obligatorie, ori dacă serviciul e disponibil doar între 
anumite intervale de timp. Toate aceste meta-date pot fi exprimate via WS-Policy 
pe baza unui set extensibil de asertiuni. Dacă WSDL se axează pe unele descrieri 
funcţionale asociate serviciilor Web, construcţiile WS-Po/cy permit atașarea de 
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descrieri non-functionale sau privitoare la asigurarea calităţii serviciilor. Alte 
aspecte, precum cele referitoare la semantica serviciilor Web, vor putea fi 
modelate de către alte prevederi (e.g, OWL-S). De asemenea, setul de politici 
exprimate de WS-Po/icy nu vizează doar punctele terminale, asa cum se întâmplă 
în cazul WSDL. 

Oferim drept exemplificare următorul fragment de document XML care 
precizează că un serviciu Web nu va fi disponibil între orele 10 și 11 în ziua de 
duminică a fiecărei săptămâni (politica efectivă se exprimă printr-un vocabular 
XML definit de noi, aparţinând spaţiului de nume ,,57): 

<wsp:Policy> 

<wsp:All> 
<s:PlanificareRevizie> 
<s:Oprire s:ziua="Duminica" 
s:start="1000" s:final="1100" /> 
</s:PlanificareRevizie> 
</wsp:All> 
</wsp:Policy> 


Diversele politici de acces pot fi atașate serviciilor prin intermediul WS-PA 
(WS-PolicyAttachment). Maniera de interschimb de meta-date este precizată de 
specificatia WS-MEX (WS-MetadataExchange), meta-datele putând fi specificate 
în diverse așa-numite dialecte (XML Schema, WSDL, WS-Policy etc.). Un exemplu 
de cerere de furnizare a meta-datelor privitoare la politicile de acces este 
următorul: 

<wsx:GetMetadata> 

<wsx:Dialect> 
http://schemas.xmlsoap.org/ws/2002/12/policy 


</wsx:Dialect> 
</wsx:GetMetadata> 


2.7. Securitatea serviciilor Web 


Aspecte generale privind securitatea 


Securitatea joacă un rol esenţial în dezvoltarea serviciilor Web. În mod general, 
aspectele privind securitatea datelor iau în consideraţie confidentialitatea, auten- 
tificarea, autorizarea, integritatea, nerepudierea, intimitatea (privacy) şi dispo- 
nibilitatea. 

Confidentialitatea se referă la imposibilitatea unei terţe entităţi să aibă acces la 
datele vehiculate între doi receptori. O soluţie ar fi aceea a constituirii unei 
conexiuni private între cele două puncte terminale ale canalului de comunicaţie, 
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datele circulând printr-un tunel oferit de o refea privată virtuală (VPN — Virtual 
Private Network). A doua soluţie este oferită de criptarea datelor prin intermediul 
unei suite de tehnici, implementate de biblioteci specializate și/sau oferite de 
mediile de dezvoltare existente. 

În unele situaţii, precum cele din domeniul e-business, accesul la serviciul Web 
nu trebuie sa fie public, acordat oricui. Autentificarea presupune un mecanism 
care permite utilizatorilor să acceseze un serviciu după verificarea identității 
utilizatorului (în general, pe baza unui nume de cont și a unei parole furnizate 
de acel utilizator). De cele mai multe ori, serverul Web oferă suport pentru 
autentificări de bază sau bazate pe algoritmi de tip digest, precum MD5. În cazul 
serviciilor Web, există însă initiative speciale, precum SAML (Security Assertion 
Markup Language) — vezi infra. 

„Autorizarea este asociată autentificárii și specifică acțiunile (rolurile) pe care un 
utilizator poate să le realizeze. Un utilizator autentificat poate să nu fie în mod 
implicit și autorizat să aibă acces la o anumită resursă a sistemului. Sistemele de 
autorizare permit administratorului să definească politici pentru controlul acce- 
sului la servicii. În mod tradiţional, se folosesc drepturi de acces (permisiuni) si 
liste de control al accesului (ACL — Access Control Lis?), utilizatorii fiind clasificați 
pe grupuri sau roluri. Prin intermediul controlului accesului bazat pe roluri 
(RBAC — Ro/e-Based Access Control), sistemul de management al securităţii poate 
fi mai uşor mulat pe structura organizaţiei. În ceea ce priveşte utilizatorul, în 
mod uzual se folosește o tehnică de tip SSO (Single Sign-On), bazat pe existenţa 
unui singur procedeu de autentificare comună pentru accesul la mai multe 
resurse (Situri, servicii etc.). 

Tehnicile de tip digest pot asigura si ifegritatea informaţiilor, fiind posibilă 
detectarea oricărei încercări malitioase de modificare a datelor transmise. De 
asemenea, tot pentru realizarea integrităţii, pot fi folosite semnături digitale (a nu 
se confunda însă cu semnăturile electronice care se referă la totalitatea mijloacelor 
prin care o informatie poate „purta” semnătura proprietarului ei). Semnăturile 
digitale pot fi stocate în format XML — si vehiculate, desigur, via mesaje SOAP — 
prin intermediul specificatiei XML Signature. 

Nerepudierea asigură faptul că expeditorul mesajului nu poate afirma că nu l-a 
trimis. Pentru aceasta se folosesc certificate digitale, care stochează datele privind 
identitatea unei entităţi deținătoare a unui secret (o parolă, o serie a unei cărți de 
credit, a certificatului digital în sine etc.). Certificate digitale sunt disponibile 
într-un format precum X.500. Un certificat digital este emis de o autoritate de 
certificare (CA — Certification Authority), iar verificarea certificatelor se realizează 
de către o autoritate de înregistrare a acestora (RA — Registration Authority). Cata- 
loagele de certificate, împreună cu autoritățile de certificare (CA) și înregistrare 


288 SERVICII WEB 


(RA) formează așa-numita zufrastructurá cu chei publice (PKI — Public Key Infrastructure). 
Oferirea de servicii PKI in contextul spatiului Web se poate realiza via XKMS 
(XML Key Management Specification). 

Disponibilitatea impune ca o anumită resursă să poată fi accesată la momentul 
oportun. Un serviciu Web indisponibil clienților săi pur si simplu nu există, ceea 
ce are repercusiuni negative mai ales în contextul afacerilor electronice. Printre 
cauzele care pot eroda disponibilitatea se enumeră atacurile de refuz al serviciilor — 
DoS (Denial Of Service) sau DDoS (Distributed DoS). Atacurile distribuite sunt 
deosebit de periculoase pentru asigurarea disponibilitatii serviciilor Web publice. 

Intimitatea este deseori confundată cu confidentialitatea. Confidentialitatea 
presupune imposibilitatea ca datele aflate în tranzit să fie accesate de persoane 
ráu-voitoare, pe când intimitatea vizează drepturile ce trebuie respectate privind 
caracterul (subiectul) datelor vehiculate. Multe dintre vulnerabilitatile raportate 
în domeniul comerţului electronic sunt de fapt breșe în sistemul de asigurare a 
intimitátii utilizatorilor. Pentru datele transportate pe Internet sunt adoptate în 
mod unanim diverse tehnici de criptare, dar la nivel de server ar putea să fie 
stocate necorespunzător (de exemplu, în clar) în cadrul unui sistem de stocare 
vulnerabil. Un atacator va avea astfel acces la seria cărții de credit a unui client, 
pe baza unei conexiuni directe cu serverul de baze de date sau a unui tehnici de 
tip XSS (Cross-Site Scripting). Alte probleme vizând pierderea intimitatii sunt 
cauzate de configurarea necorespunzătoare a sistemelor — detalii și în cartea lui 
Sabin Buraga, Proiectarea siturilor Web (ediţia a doua), Polirom, Iasi, 2005. 


Niveluri de securitate 


Vom face mai jos o scurtá trecere in revista a cerintelor de securitate pe care 
trebuie să le îndeplinească serviciile Web. 

Construirea unor servicii Web sigure (din punctul de vedere al securității) 
trebuie să ia în considerare aspecte ca: 


— realizarea unui model (Web Services model care are la bază o analiză detaliată a 
factorilor care amenință comunicarea și punctele terminale (endpoints) ale 
serviciilor Web; 

— existența unui cadru de lucru (framework) facilitând securizarea resurselor, uşor 
integrabil într-o arhitectură orientată spre servicii; 

— asigurarea unui mecanism de autentificare și autorizare a părților care comu- 
nică în cadrul sistemului constituit. 


Majoritatea scenariilor de securitate sunt legate de securitate la nivel de retea/ 
transport, securitate la nivel de date și integritate la nivel de mesaj. 
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La nivel de rețea, mijlocul de protecţie generală împotriva incidentelor de 
securitate se concretizează în așa-numitul zid de protecţie (firewa/). Deoarece 
serviciile Web folosesc în mod nativ protocolul HTTP, mesajele vehiculate vor 
putea traversa Internetul fără aportul filtrelor impuse de frewal/-uri (acesta este, 
de fapt, si unul dintre avantajele serviciilor Web fata de tehnologiile CORBA sau 
DCOM). Totuși, frewal/-urile vor fi de folos pentru stăvilirea altor tipuri de 
atacuri, de nivel inferior (eg, inundări cu pachete). De asemenea, la nivel de 
rețea poate fi folosit protocolul IPSec (IP Secure). 

În ceea ce priveşte nivelul de transport, se recurge la SSL (Secure Sockets Layer) 
si la versiunea mai recentă, standardizată, TLS (Transport Layer Security). Aceste 
protocoale sunt folosite pentru autentificarea si confidentialitatea mesajelor 
HTTP. Autentificarea se realizează via certificate digitale, iar confidentialitatea 
prin criptare. Datele HTTP securizate via SSL/TLS fac obiectul specificatiei 
HTTPS, portul folosit fiind 443, în loc de cel implicit — 80. 

La nivel de aplicaţie, în primul rând se poate utiliza S/MIME (Secure 
MIME), soluţie pentru asigurarea confidentialitatii, integrității şi nerepudierii 
în cazul mesajelor de poștă electronică. Dacă se adoptă o metodă de transfer 
SOAP peste SMTP, atunci S/MIME poate fi atractiv și în cazul serviciilor 
Web. 

Pentru HTTP sau alte protocoale (e.g., Jabber), un prim deziderat este să se 
ofere o securitate persistentă a mesajelor SOAP transportate. Tehnologiile 
amintite mai sus vizează o securitate exterioară. Includerea de informaţii privind 
securitatea în cadrul unui mesaj SOAP este subiectul specificatiei WS-Security, 
actualmente standard OASIS. WS-Security defineşte metode speciale de inserare 
a datelor criptate sau a semnáturilor digitale in anteturile SOAP. In plus, se oferă 
suport pentru includerea de jetoane (kens) de securitate arbitrare. Alte detalii 
vor fi furnizate mai târziu în cadrul acestui capitol. 


Securitatea în contextul XML 


Confidentialitatea este asigurată via XML Encryption, specificaţie a Consortiului 
Web, care ofera mijloacele pentru criptarea unor portiuni din documentele XML 
si stocarea datelor criptate in format XML. XML Encryption poate fi benefic in 
contextul serviciilor Web, datorită abilității criptării doar a unor fragmente XML. 
Mesajele SOAP pot include informaţii care trebuie să rămână publice (privitoare 
la dirijare, de exemplu), dar pot conţine si parti criptate. Standardul XML 
Encryption nu introduce noi algoritmi de criptare, putând fi folosiţi cei deja 
consacraţi, ci doar specifică anumite meta-date referitoare la aceștia și la modul 
de utilizare într-un context dat. 
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Un exemplu de criptare a informatiilor privitoare la cartea de credit a unui 
utilizator este următorul (numele clientului e public, dar celelalte informaţii 
private sunt criptate — în acest caz, se folosesc și semnături digitale): 


<?xml version='1.0'?> 
«plata xmlns-'http://portocale.info/Plati'» 


<nume>Portocal Escu</nume> 
<EncryptedData Id-'EData' 
xmlns-'http://www.w3.org/2001/04/xmlenci'» 
«EncryptionMethod Algorithm- 
'http://www.w3.0rg/2001/04/xmlenctaes128-cbc'/» 
«ds:KeyInfo xmlns:ds- 
"http: //www.w3.org/2000/09/xmldsig#'> 
<ds:RetrievalMethod URI='#EKey' Type- 
"http://www.w3.org/2001/04/xmlenc#EncryptedKey"> 
«ds:KeyName»SymmetricKey«/ds:KeyName» 
</ds:RetrivalMethod> 
</ds:KeyInfo> 
<CipherData> 
<CipherValue>pj3io2sa25fF</CipherValue> 
</CipherData> 
</EncryptedData> 
</plata> 


Pentru rezolvarea integrităţii, avem la dispoziție XML Signature, specificaţie 
comună a Consortiului Web şi a IETF (Internet Engineering Task Force). Ca mai sus, 
se oferă atât posibilitatea semnării digitale a unor porțiuni dintr-un document 
XML, cât și exprimarea în XML a informaţiilor referitoare la semnăturile 
digitale. Modul de integrare a elementelor XML Signature în cadrul mesajelor 
SOAP este detaliat de specificatia WS-Security. 

Problemele de autentificare și autorizare în contextul serviciilor Web se 
încearcă a fi rezolvate de o suită de tehnologii. Diverse declaraţii privitoare la 
anumite aspecte legate de securitate pot fi exprimate cu ajutorul SAML (Security 
Assertions Markup Language), standardizat de OASIS. Limbajul SAML poate fi de 
folos si pentru stocarea unor informaţii privitoare la utilizatorul final (e.g., 
precizarea unei limite inferioare a unui depozit bancar în cazul unui serviciu de 
creditare). SAML este utilizat mai ales pentru a specifica informaţii referitoare la 
autentificare sau autorizare care s-au întâmplat în trecut, permiţând ca aceste 
informaţii să fie plasate într-un mesaj SOAP (de exemplu, „persoana P a fost 
autorizată conform unor politici de acces A la momentul M"). Dacă destinatarul 
acelui mesaj are încredere in asertiunea (assertion) semnalată prin SAML, poate 
permite utilizatorului să aibă acces la serviciul Web dorit. 
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Solicitant Ofertant 


Nivel de transport (HTTP, SMTP) 


Figura 5. Procesul de criptare/descriptare a mesajelor SOAP 


Drept exemplificare, furnizăm următorul fragment de document, care pre- 
cizează că autentificarea utilizatorului b/ve.ory s-a realizat cu succes, pe baza 
metodei de autentificare oferită de sistemul Kerberos: 


<saml:AuthenticationStatement 
AuthenticationInstant="2006-09-01T10:33:332" 
AuthenticationMethod="Kerberos"> 
<saml:Subject> 
«saml:NameIdentifier 
NameQualifier="verisign.com/ams"> 
blue.ory 
«/saml:NameIdentifier» 
«/saml:Subject» 
</saml:AuthenticationStatement> 
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Suplimentar, pentru a exprima regulile de control al accesului in termenii 
XML, putem recurge la XACML (Extensible Access Control Markup Language). 
Decizia de autorizare modelata printr-o asertiune SAML poate fi bazata pe 
regulile stipulate via XACML. Regulile pot desemna politici de acces la resurse 
(citire, scriere, execuţie etc.) bazate pe diverse caracteristici ale entității în cauză 
(e.g. „lista clienților poate fi parcursă doar de membrii departamentului de 
vânzări”) sau ale protocolului („invocarea serviciului Web se poate realiza numai 
via HTTPS”). De asemenea, XACML poate fi folosit si la managementul 
drepturilor digitale - DRM (Digital Rights Management). 

Specificatia XKMS (XML Key Management Specification) ofera suportul pentru 
gestiunea cheilor publice via XML. Astfel, în mod natural, serviciile PKI — 
recunoscute a fi dificil de implementat — pot fi puse la dispoziţie mai facil, graţie 
serviciilor Web. Recomandarea XKMS presupune existenţa a două servicii Web: 


— X-KRSS (XML Key Registration Service Specification) trebuie să ofere suport 
pentru managementul ciclului de viata al acreditărilor (credentials) asociate 
cheilor publice; 

— X-KISS (XML Key Information Service Specification) expune metode de interogare 
pentru obţinerea si validarea cheilor publice. 


Protocolul XKMS este în strânsă legătură cu SOAP, fiind de tip cerere- 
-răspuns. De asemenea, se oferă facilități pentru procesări asincrone și formularea 
de cereri compuse. Via XKMS, complexitatea virează de la client la intrastructurá, 
codul de implementat fiind mult mai simplu. 


Securizarea serviciilor Web. Tehnologii si standarde 


Tehnologiile prezentate mai sus nu se focalizează în principal asupra securității 
serviciilor Web, ci iau în consideraţie si securitatea datelor XML. 

Pentru securizarea mesajelor SOAP a fost redactat un set de specificații 
purtând numele WS-Security, efort comun al corporațiilor IBM si Microsoft, 
actualmente standardizat de OASIS. Aspectele de securitate nu mai vizează în 
mod obligatoriu protocolul folosit (¢g., HTTP cu TLS), ci se situează la nivelul 
mesajelor, în termeni de asigurare a integrităţii, confidentialitátii si autentificarii. 
WS-Security include si alte specificaţii, precum WS-Trust (pentru asigurarea 
încrederii), WS-SecurityPolicy (privitoare la politici de acces sigur) si WS-Privacy 
(pentru asigurarea intimitátii). La un nivel superior, se află WS-SecureConversation 
(având in vedere siguranța conversatiilor între serviciile Web), WS-Federation 
(vizând gruparea serviciilor într-o federație partajand aceleași politici de securi- 
tate) si WS-Authorization (oferind suport pentru metode de autorizare sofisticate). 
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Figura 6. Diversele aspecte privind securitatea serviciilor Web sunt specificate pe niveluri 


WS-Trust defineşte modul de stabilire a relaţiilor de încredere într-un sistem. 
Aceste relații pot avea loc direct sau prin intermediari (broken). Intermedierea 
relaţiilor de încredere se realizează printr-un proxy de încredere (trust proxy). De 
asemenea, se permit mecanisme pentru delegare (de/egation) și impersonalizare 
(impersonation). 

Prevederile WS-SecurityPolicy pot fi utilizate pentru formularea unor politici de 
securitate pe baza limbajului WS-Policy. 

WS-Privacy foloseşte WS-SecurityPolicy, WS-Security şi WS-Trust pentru a realiza 
schimburi de mesaje conform unor reguli de asigurare a intimității. 

Specificatia WS-SecureConversation permite ca un solicitant și un ofertant de 
servicii Web să stabilească un context de autentificare mutuală prin mesaje 
SOAP. 

WS-Federation duce securitatea la nivel de federație de servicii Web, unde 
„federație? presupune inter-operabilitatea diverselor strategii și specificații de 
securitate folosite de o suită de servicii Web, care formează un domeniu de 
încredere. WS-Federation poate fi folosit si în contextul EASI (Enterprise Application 
Security Integration). 

WS-Authorization poate fi considerat complementar XACML, descriind maniera 
de specificare si de management al politicilor de acces la serviciile Web. 

Din punct de vedere tehnic, WS-Security presupune existența într-un mesaj 
SOAP a unui bloc antet Security care trebuie să aibă prevăzut atributul z/5Understand 
cu valoarea sue: 


<Envelope> 
<Header> 


<Security role="http://www.portocale.info/Plati" 
mustUnderstand="true"> 
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</Security> 


</Header> 


</Envelope> 


Dacă un nod SOAP este incapabil să proceseze blocul privitor la securitatea 
mesajului, atunci mesajul va fi distrus. Deoarece un mesaj poate include mai 
multe blocuri Security, vom indica prin atributul rok cărui serviciu Web îi sunt 
adresate informaţiile de securitate din fiecare bloc în parte. Conţinutul propriu-zis 
al elementului Security va consta din jetoane (tokens) de securitate, precum 
Usernameloken (referitor la autentificare prin SAML ori alte tehnici) și 
BinarySecurity Token (privitor la diverse date criptate, exprimate cu XML Signature, 
XML Encryption sau altfel). 

De asemenea, se precizează și diverse scenarii de manipulare a erorilor 
survenite via elementul Faz// oferit de SOAP. 

Actualmente, unul dintre cele mai versatile instrumente care suportă WS-Security 
este extensia WSE (Web Services Enhancements) versiunea 3.0 pentru .NET Framework. 
De exemplu, criptarea unui mesaj SOAP prin folosirea unui certificat digital in 
format X.509 (care trebuie să se găsească pe fiecare calculator al clientului ce 
solicită o informatie confidențială de la serviciul Web) poate fi realizată astfel: 

X509SecurityToken certificat = FurnizeazaCertificat(); 

// adăugăm jetonul privitor la certificat 


serviciu.RequestSoapContext.Security.Tokens.Add 
(certificat); 


// inserám un element EncryptedData 
serviciu.RequestSoapContext.Security.Elements.Add( 
new EncryptedData (certificat)); 


Mentionam cá WSE nu ofera doar facilitati in ceea ce priveste securitatea 
serviciilor Web, ci si pentru adresare (IV. $ Addressing) si atasare de alte informaţii 
la mesajele SOAP (WS-Attachments). Sunt puse la dispoziţie si diverse instrumente 
utile ce pot fi integrate fără probleme in Visual Studio.NET. De asemenea, WSE 
facilitează exploatarea serviciilor Web create in .NET si prin intermediul unor 
protocoale diferite de HTTP. 
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2.8. Asigurarea inter-operabilitátii 


Inter-operabilitatea vizează existenţa unei suite de tehnici și instrumente care 
permit aplicaţiilor software (în cazul nostru, serviciile Web și clienţii aferenti) să 
comunice indiferent de tehnologiile și platformele folosite. Mai mult decât atât, 
aplicaţiile pot partaja datele indiferent de manierele de reprezentare, de acces și 
de tehnologia folosită la momentul rulării pentru managementul acestor date. De 
asemenea, inter-operabilitatea presupune posibilitatea formării unei platforme 
virtuale de calcul, pe baza sistemelor de operare, mediilor de rulare (runtime) si 
componentelor software trecute, prezente și viitoare. 

Tehnologiile actuale menite a oferi sprijin pentru realizarea inter-operabilitatii 
sunt WSIT (Web Services Interoperability Technology), JWSDP (Java Web Services 
Developer Pack), WSE (Web Services Enhancements) şi WCE (Windows Communication 
Foundation). La momentul scrierii acestui material, JWSDP se află la versiunea 2. 
După cum am menţionat în secțiunea anterioară, WSE reprezintă o extensie 
oferită de Microsoft pentru dezvoltarea de servicii Web securizate și inter- 
operabile pe platforma .NET, actualmente fiind disponibilă versiunea 3.0. WSE 
are la bază specificaţii standardizate, precum WS-Security, WS-Addressing, WS-Policy 
si WS-I. WCF — cunoscut anterior si sub numele Indigo — desemnează una dintre 
componentele fundamentale ale noului sistem Windows Vista, menită a oferi o 
infrastructură pentru comunicarea prin mesaje între diverse componente. 

O inițiativă importantă de standardizare referitoare la inter-operabilitatea 
serviciilor Web este WS-I (Web Service Interoperability), detalii fiind disponibile la 
hitp:| /www.ws-i.org. 

Principalele avantaje ale inter-operabilitatii sunt cele privind asigurarea inde- 
pendentei de platforma, evolutia bazata pe standarde deschise si utilizarea 
familiei XML. Printre slăbiciuni se numără problemele de performanţă, difi- 
cultatea gestionării per ansamblu a stării sistemului, problemele cauzate de 
incompatibilitatea datelor (data mismatch) din cauza interpretărilor diferite ale 
standardelor implementate de diversi ofertanti. De asemenea, nu întotdeauna 
poate fi folosit modelul cerere/răspuns, mai ales în cazul unor aplicaţii care 
trebuie să fie executate în timp-real sau care necesită transferuri de fluxuri de 
informații (streaming). 

Aspectele importante pe care trebuie să le avem în vedere când concepem 
servicii Web care să asigure o inter-operabilitate solidă se referă la: 


— tipurile de date și schemele XML proiectate si folosite în cadrul documentelor 
WSDL (se recomandă ca, înainte de implementarea propriu-zisă a serviciului, 
să se realizeze o analiză și proiectare corespunzătoare a schemelor XML 
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privitoare la mesajele vehiculate între serviciile Web si posibilii lor clienţi; de 
asemenea, o atenţie deosebită trebuie acordată documentului WSDL de 
descriere a serviciului, deoarece este unicul mijloc prin care un dezvoltator 
extern are acces la functionalitatile serviciului în cauză); 

— alinierea la standardele în vigoare (mai ales la WS-I, prezentat mai jos); 

— controlul versiunilor (versioning); 

— compatibilitatea cu variantele anterioare ale instrumentelor folosite (de exemplu, 


JWSDP 1.x/2.x versus WSE 2.0/3.0 sau WCF). 


Etapa de proiectare vizează alegerea tipurilor de date, scrierea schemelor 
XML și stabilirea modului de tratare a erorilor. Primul pas este cel de definire a 
schemei XML, construcţiile folosite fiind cât mai simple posibil (a se evita 
aspectele avansate privitoare la reprezentarea datelor via XML Schema). Tot aici, 
trebuie să avem in vedere profilele de inter-operabilitate WS-I. Nu trebuie să 
presupunem că tipurile de date vor fi verificate de clienţi, că versiunea SOAP 
folosită de diversele implementări este și va rămâne aceeași, că transferurile de 
date vor fi realizate doar în manieră sincronă. De asemenea, este posibil ca 
instrumentele utilizate să nu fie compatibile între ele. 

În faza de dezvoltare trebuie avute în vedere aspecte privind comunicațiile 
asincrone, partajarea datelor/sesiunilor, mecanismul de mesagerie folosit și 
securitatea. 

La momentul exploatării în practică, principalele probleme sunt cele legate de 
performanţă şi scalabilitate. 

Inter-operabilitatea poate fi asigurată și prin interpunerea unei componente 
de tip wrapper, care transformă mesajele clientului în formatul înţeles de către 
serviciu si invers. Acest wrapper poate fi situat la nivel de server, la nivel de client 
sau într-un strat intermediar. Există situaţii în care se folosesc două componente 
wrapper, una pe mașina clientului, cealaltă pe server. Soluțiile care permit realizarea 
acestui „pod” (bridging) de conectare a două aplicaţii incompatibile folosesc fie 
tehnologiile Java, fie .: NET (via .NET Remoting). 

Alternativ, inter-operabilitatea poate fi obţinută graţie sistemelor messaging, 
folosind punti de interconectare, adaptori, mesaje SOAP ori sisteme de mesagerie 
clasică SMTP/POP/IMAP. În acest caz, comunicațiile pot fi și asincrone. 

Pentru aplicații compuse (composite applications), Sun propune o arhitectură 
denumită „magistrala de servicii enterprise’? — ESB (Enterprise Service Bus), constituită 
din componente pentru managementul și orchestrarea sofisticată a tuturor 
activităţilor din cadrul unei organizaţii, asigurându-se inclusiv inter-operabilitatea. 
În viziunea Sun, ESB reprezintă o etapă evolutivă superioară SOA, oferindu-se 
suport pentru existența componentelor hibride, a unui management centralizat 
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si a unor entități middleware orientate spre mesaje. De asemenea, prin ESB se 
inlesneste asigurarea scalabilitátii. 


fiabile 
Enterprise 


re. ant 
Service 


de servicii 


P 
Lis 


Figura 7. Componentele ESB 


In ce priveste aplicatiile compozite, ele sunt constituite din servicii reutilizabile, 
putand fi create usor, frecvent si la cerere, conform cerintelor afacerilor intre- 
prinse. Aspectele statice, mai riguroase, ale aplicației sunt separate de cele 
dinamice, in evolutie, conforme cu preferintele utilizatorilor. Daca Java poate fi 
limbajul folosit la implementarea aplicaţiilor, compunerea serviciilor poate fi 
realizată prin BPEL4WS; a se urmări cele discutate în secțiunea de mai jos. 

Aliniate arhitecturii ESB, sunt disponibile atât produse comerciale — oferite 
de BEA, Cape Clear, IBM, Oracle ori Sun —, cât si aplicaţii open source — de 
exemplu, Ce/tix (IONA), FUSE (LogicBlase), Open ESB (Sun), Synapse (Apache) 
si ServiceMix (Apache). 

Direcţiile de viitor vizează — ori, de fapt, visează? — unificarea platformelor 
J2EE (Java 2 Enterprise Edition) şi NET. Astfel, pot fi adoptate extensii JZEE care 
să permită aplicaţiilor INET să ruleze pe un anumit server de aplicaţii Java. De 
asemenea, poate fi constituit un strat de translatare la momentul compilării a 
codului din limbajul intermediar MSIL în secvenţe de bytecode Java si vice-versa. 
În acest mod, sistemul de operare poate găzdui o unică mașină virtuală capabilă 
să „înţeleagă” ambele tehnologii (instrucţiuni de nivel scăzut, sistem de tipuri de 
date, componente etc.). Aplicațiile .NET pot „consuma” resurse Java, in mod 
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direct, si invers. Aceste maniere de inter-operabilitate sunt deja suportate de 
aplicații precum JBoss, Tomcat, WebLogic si WebSphere. De asemenea, Visual 
MainWin pentru J2EE reprezintă un plug-in Visual Studio care permite dez- 
voltatorilor să scrie programe C# sau VB.NET (inclusiv servicii Web) care sunt 
convertite automat dupa compilare in bytecode Java. 

Pe o idee oarecum similară se bazează si noua versiune Perl 6, via mașina 
virtuală Parrot, aflată în plină dezvoltare. 

În ceea ce priveşte Java, noile versiuni J2SE 1.6 si J2EE 1.5 pun un accent 
pronunţat asupra asigurării inter-operabilitáti. Un exemplu este si GlassFish, 
disponibil gratuit pentru utilizare, parte a proiectului Tango, al cărui scop este 
oferirea unei suite de tehnologii Web viitoare care să permită inter-operabilitatea 
dintre aplicațiile Java si cele WCF, pe baza strategiilor WSIT (Web Services 
Interoperability Technology) stipulate de corporatia Sun. 


Profilul WS-I de bază 


Pentru a nivela posibilele diferenţe între implementările oferite de diversele 
medii de dezvoltare a serviciilor Web, organizația WS-I a redactat un prim profil — 
denumit profilul de bază (WS-I Basic Profile) — la care trebuie să se alinieze toate 
implementările actuale. În prezent este în vigoare versiunea 1.1 a acestui profil. 
Una dintre prevederile majore ale profilului este aceea a interzicerii codificarii în 
stilul RPC a mesajelor SOAP. 

Pentru a indica faptul că o implementare este conformă cu profilul de bază, 
de cele mai multe ori se recurge la specificatori (meta-date) precum cei dati mai 
jos (aici, pentru .NET): 


[WebService 
[WebServiceBinding ( 
ConformsTo = WsiProfiles.BasicProfilel 1) ] 
public class Serviciu : System.Web.Services.WebServic 


{ 


// implementare 


În viitor, WS-I ar putea standardiza si alte profile privitoare la diversele 
aspecte ale inter-operabilitátii serviciilor Web. 


2.9. Serviciile Web în contextul proceselor de afaceri 


Este de necontestat faptul că serviciile Web si arhitectura orientată spre servicii au 
devenit paradigma obișnuită pentru proiectarea și implementarea colaborărilor la 
nivel de afaceri în cadrul și dincolo de graniţele unei organizaţii. Functionalitatile 
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sunt oferite prin intermediul interfetelor standardizate ale serviciilor Web. 
Serviciile puse la dispoziţie de diferite organizaţii, eventual regăsite gratie UDDI, 
pot fi interconectate în vederea realizării de operaţii (relativ mai) complexe. 
Astfel, grupuri de servicii considerate atomice constituie așa-numitele servicii 
compozite (composite Web services). 

Colaborările inter- sau intra-organizationale necesită in multe cazuri interac- 
tiuni de durata, conduse de modele explicite de procese de afaceri. Modelarea 
proceselor de afaceri se regăsește și sub termenii de model al fluxului de 
activități (workflow), orchestrare sau coregrafie. 

Există deja o suită de limbaje XML de modelare a proceselor de afaceri, 
distingându-se WSCI (Web Service Choreography Interface), BPML (Business Process 
Modeling Language) şi BPEL4WS (Business Process Execution Language for Web Services). 
Aceste abordari iau in consideratie atat manierele de comunicare intre diversele 
entități software implicate, cât si workflow-urile desfăşurate într-un sistem. 

Vom discuta în continuare câteva dintre aspectele definitorii ale BPEL4WS. 
Acest limbaj are ca strămoși WSFL (Web Services Flow Language) oferit de IBM si 
propunerea XLANG inițiată de Microsoft. Dacă primul modela un flux de 
activități ca un graf orientat specificat de construcţii XML, al doilea avea un 
punct de vedere apropiat de scrierea în pseudo-cod a algoritmilor. 

Un proces reprezintă orice colecţie de activităţi care conduc la realizarea unui 
anumit obiectiv (de exemplu, procesarea unei comenzi ori cereri de plată, 
angajarea unui nou programator într-o companie sau trimiterea unei propuneri 
de invenţie spre aprobare). 

În viziunea BPELAWS, procesele pot fi abstracte sau executabile. Cele 
abstracte desemnează un protocol specificând tipul mesajelor interschimbate de 
diverse entităţi, fără a se oferi detalii privitoare la comportamentul acestora. 
Procesele executabile definesc: 


— o ordine de execuţie a activităţilor constituiente; 
— partenerii implicați; 

— mesajele vehiculate între parteneri; 

— mecanismele de rezolvare a exceptiilor/erorilor. 


La rândul ei, o activitate — parte componentă a unui proces — poate fi simplă 
(primitive) sau structurată (structured). Tipurile de activităţi simple sunt următoarele: 


— invoke — invocarea unei operaţii oferite de un serviciu Web și descrise de un 
document WSDL; 

— receive — aşteptarea unui mesaj provenind de la o sursă externă; 

— reply — trimiterea unui mesaj-replică unei surse externe; 
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— wait — Oprirea activităţii un anumit timp; 

— assign — copierea datelor dintr-o variabilă în alta; 
— throw — indicarea erorilor survenite într-o execuţie; 
— terminate — terminarea unei instante de serviciu; 

— empty — desemnează activitatea vida. 


bancar 


Figura 8. Reprezentarea grafică a unui workflow desfășurat în cazul inițierii unei comenzi din 
partea unui cumpărător online ce doreşte să achiziționeze un sortiment de portocale 


Operatiile complexe pot fi modelate prin activităţi structurate. Astfel, pot fi 
specificate structuri foarte similare celor puse la dispoziţie de limbajele de 
programare: 
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sequence — defineşte o ordine de execuţie, secventiala; 


switth — desemneaza o alternativa (conditional routing); 


while — permite bucle de execuţii; 

— pick — stabileşte condiţii de alegere bazate pe evenimente (eg, onAlarm, 
onMessage etc.); 

— flow — permite execuţia in paralel (parallel routing); 


scope — grupează activități ce vor fi tratate de același handler de excepții. 


Varianta 2.0, mai recentă, a limbajului introduce noi tipuri de activităţi 
(if-then-else, forEach, repeatUntil, validate etc.) şi transformări ale valorilor variabilelor 
prin XSLT. De asemenea, este aliniată la prevederile în vigoare privind inter- 
-operabilitatea. 

Procesul de verificare a stocului de portocale poate fi modelat astfel (este 
vorba de o comunicare sincronizata): 


<process name="verifStocPorto"> 


<sequence> 
<!-- dorim să aflăm cantitatea disponibilă 
de portocale --> 


«invoke partner="stocuri" 
inputVariable="portocale" 
outPutVariable="cantit"> 

</invoke> 


<flow> 
<!-- alte activități care nu depind 
de 'cantit' --> 
<sequence>...</sequence> 
<!-- obtinem cantitatea --> 


<receive partner="stocuri" 
variable="cantit"></receive> 
</flow> 
</sequence> 
</process> 


Desigur, activităţile structurate pot fi imbricate. In cazul activităţilor care fac 
parte din aceeași activitate de tip flow, ordinea de execuţie poate fi controlată via 
links — legături ce permit definirea dependentelor între două activități (activitatea 
destinaţie poate începe doar atunci când activitatea sursă s-a încheiat). Astfel se 
formează un digraf aciclic de activităţi, cu condiţii de tranziţie de la o activitate 
la alta (7ransifion conditions) si condiţii de unificare (join conditions). 

Vom exemplifica două dintre sabloanele de realizare a workflow-urilor: alegerea 
exclusiva (exclusive choice) şi confluenta simplă (simple merge). 
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Alegerea exclusiva presupune, pe baza luarii unei decizii, alegerea unei singure 
soluţii dintr-o alternativă. De exemplu, managerul unui magazin virtual va fi 
notificat dacă stocul de portocale este pe sfarsite (cantitatea disponibilă este mai 
mică de 33 de kilograme), altfel nu. Schematic, aceasta poate fi exprimată prin 
liniile: 

<switch> 

<case condition="#cantitMinima"> 
<!-- notificăm managerul ==> 


</case> 
<case condition="..."> 


</case> 

</switch> 

Confluenta simplă precizează un punct din procesul workflow in care se 
reunesc două sau mai multe ramuri de activități alternative, fără a necesita 
sincronizare (se presupune însă că ramurile alternative nu se execută niciodată în 
paralel). De exemplu, după ce plata a fost efectuată sau creditul a fost aprobat, 
produsul comandat poate fi expediat clientului. 

Actualmente sunt disponibile diverse sisteme de management al fluxurilor de 
activități — WFMS (WorkFlow Management System) —, majoritatea oferind suport 
pentru BPEL4WS ori alte propuneri complementare. Ca exemple notabile 
menționăm instrumentele oferite de BEA, Microsoft, Oracle si Sun, care functio- 
nează pe platforme precum .NET, J2EE sau JBI (Java Business Integration). 

Ca alternativă la ESB (care oferă suport si pentru workflow-uri), corporatia 
Microsoft are în vedere constituirea a ceea ce numeşte Windows Workflow 
Foundation, integrată cu tehnologiile Microsoft, dar a cărei arhitectură se bazează 
pe modelul unui procesor (engine) BPEL. La nivel de utilizator final, workflow-urile 
pot fi definite grafic direct în Office, iar dezvoltatorii vor avea la dispoziție 
diverse aplicații precum Visual Studio Team System. Actualmente, fluxurile de 
activități sunt folosite în cadrul serverului Biz 1a/& si a noii fundații de servicii de 
comunicare WCF (Windows Communication Foundation). 


2.10. Servicii Web pentru grid 


Orchestrarea si coordonarea sunt esentiale si in cadrul sistemelor de tip grid, in 
cate serviciile Web joacă un rol important. Conceptul de grid desemnează o 
entitate oferind servicii de calcul sau acces la date și fiind compusă dintr-o serie 
de computere privite ca o gazdă Internet unică. Dacă initial au reprezentat o 
propunere de infrastructură de calcul distribuit pe scară largă destinată proiectelor 
ştiinţifice si industriale, tehnologiile grid au oferit ulterior suport pentru căutarea 
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si regăsirea informaţiilor, indiferent de localizarea lor fizică. Într-un sistem grid, 
serviciile pot fi dinamice si volatile, constituite ad-hoc, disponibile pe scară larga 
și pe termen îndelungat. 

O implementare de referință a arhitecturii și protocoalelor grid este Globus, 
actualmente ajunsă la versiunea 4. Instrumentele de dezvoltare formează Globus 
Toolkit, disponibile in general pentru sistemele UNIX/Linux. Interfetele de 
programare formează așa-numitul CoG (Commodity Grid) toolkit, fiind disponibile 
pentru limbaje precum Java, Perl ori Python, cu suport si pentru CORBA, .NET si 
servicii Web. Standardizarea tehnologiilor grid este supervizata de Global Grid Forum. 

În prezent, atenţia este focalizată asupra constituirii unei arhitecturi orientate 
spre servicii grid, recurgandu-se la tehnologiile Web actuale. Astfel, în cadrul 
modelul arhitectural OGSA (Open Grid Service Architecture) serviciile Web sunt 
extinse pentru a putea specifica functionalitati de baza si specializate pentru 
sisteme de tip grid. Arhitectura OGSA este compusă din infrastructura OGSI, o 
suită de interfeţe și de modele. 

OGSI (Open Grid Services Infrastructure) se află la convergenta dintre grid si 
serviciile Web, definind mecanismele de bază pentru managementul instanţelor 
de servicii grid (transferul de mesaje, menţinerea ciclului de viata etc.). OGSI 
extinde WSDL pentru a oferi servicii dependente de stare (stateful) — utile pentru 
gestionarea stării globale a sistemului —, moștenirea interfetelor serviciilor, 
notificarea asincrona a schimbărilor de stare, specificarea referintelor la instante 
de servicii și altele. De asemenea, sunt definite mecanismele prin care clienţii pot 
avea acces la serviciile gr/d-ului. 


Automat 
de stări 


(state machine) 


- resurse 


- sesiune 


- conexiuni 
- variabile 


Instanta 2 


Figura 9. Menfinerea stării fiecărei instante de serviciu Web existent într-un grid 


304 SERVICII WEB 


Interfetele (OGSA Platform Interfaces) reprezintă diverse servicii (interfeţe + 
comportamente asociate) care nu sunt definite in cadrul OGSI. Se vizeaza astfel 
un nivel superior de servicii, precum accesul si integrarea datelor, inregistrarea si 
managementul resurselor, asigurarea securităţii, jurnalizarea distribuită, orchestra- 
rea serviciilor etc. 

Modelele (OGSA Platform Models) sunt o combinaţie de interfeţe și scheme de 
date utile la reprezentarea entităţilor — eg., un server de stocare — care sunt 
incluse într-un sistem grid. 

Maniera de atasare a serviciilor la infrastructura de transport Internet, 
specificarea gazdelor, serviciile specifice unui domeniu de activitate nu fac 
subiectul specificatiilor OGSA, putand fi definite fie de anumite profile, fie de 
terțe organizații. 

În plus, OGSA defineşte WS-Agreement, prin intermediul căreia se specifică 
modul în care serviciile grid sunt gestionate conform scopurilor unor organizații 
sau cerințelor aplicaţiilor ce trebuie rulate pe grid, pe baza unor contracte 
(agreements) prestabilite sau realizate dinamic. 

În legătură cu OGSA, trebuie semnalată și inițiativa WSRF (Web Services 
Resource Framework), o familie de specificaţii vizând accesarea resurselor prin 
servicii Web, în manieră stateful. 

O altă direcţie este DAIS (Data Access and Integration Services) prin care sunt 
desctise mecanismele de acces la date la nivel inalt, ascunzandu-se detaliile 
privitoare la integrarea datelor stocate in surse multiple, având reprezentări diferite. 

Implementările OGSA se axează asupra tehnologiilor Java si NET. Unul 
dintre proiectele interesante de dezvoltare este WSRE.NET, bazat pe specificaţiile 
WSRF si implementat in C# sub .NET Framework. 

Accesul la resursele unui grid poate fi facilitat de existenta unui portal, 
deseori oferind o interfaţă Web. În acest context, menţionăm iniţiativele WSRP 
(Web Services for Remote Portlets) si WSIA (Web Services for Interactive Applications). 


3. SOA în contextul noului Web 


Din cele prezentate mai sus, putem deduce ca in cadrul SOA pot exista mai 
multe roluri pe care un dezvoltator Web poate să le joace. În primul rând, cel de 
implementator de servicii, activitate care presupune crearea si publicarea imple- 
mentarilor serviciilor rezultate. O a doua ipostază o reprezintă consumatorul de 
servicii, a cărui misiune — circumscrisă celei a dezvoltatorului de servicii — este 
de a concepe aplicatii-client menite a invoca suite de servicii. Un rol nou il deţine 
dezvoltatorul de compuneri de servicii care proiectează, generează și publică o 
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clasă de servicii compuse din alte servicii. Cel de-al patrulea tip vizează asamblarea 
serviciilor înrudite în vederea exploatării (deployment) efective și a managementului 
operaţiilor. 

Modelul de creare a aplicaţiilor și sistemelor utilizând SOA este descris de o 
specificaţie intitulată SCA (Service Component Architecture), propusă la finalul anului 
2005 de o serie de companii. Conform SCA, se oferă o modalitate neutră — din 
punctul de vedere al platformei și limbajului de programare — pentru repre- 
zentarea serviciilor care pot fi rulate pe o varietate de medii. Aceste servicii pot 
fi compuse, implementate de o paletă largă de framework-uri si containere (e.g., 
EJB — Enterprise Java Beans). La nivel de implementare, proiectul Apache Tuscany 
ofera suport pentru SCA, in limbajele C++ si Java. De asemenea, poate fi 
mentionat si Eclipse STP (SOA Tools Project). 

Daca SOA permite adoptarea unei abordari sistematice de compunere dina- 
mică a serviciilor conform cerinţelor industriei, noua direcţie de evoluţie a 
spaţiului WWW — denumită Data Web sau Web 2.0 — exprimă dorința de existenţă 
a unui mecanism flexibil de integrare ad-hoc a resurselor, fără constrângeri. Modul 
de utilizare a Web-ului actual se bazează pe modele de interacțiune bogată 
(aspect posibil via tehnologii ca RSS, Atom și AJAX) și pe crearea de reţele 
sociale slab-conectate (a se vedea fenomenul b/ogging, corelat cu existenţa taxo- 
nomiilor create de grupuri de persoane — folksonomies — si a aplicaţiilor colaborative 
de tip wik). Web-ul este văzut ca o platformă si nu numai ca depozit de date, în care 
comunităţi de utilizatori generează conţinut util (pe baza inteligenţei colective). 

În acest context, apare tipul de aplicaţie Web hibridă (așa-numitul mash-up) 
care reprezintă un sit Web ori o aplicaţie Web ce combină în mod agil conținuturi 
provenite din mai multe surse, în vederea oferirii unei interacțiuni complexe. 
Sursele sunt în mod uzual RSS feed-uri asociate b/og-urilor sau wiki-urilor si 
servicii Web exploatate prin SOAP ori prin REST. Pentru a facilita această 
integrare, numeroși ofertanti de servicii Web — începând cu Google si Amazon 
si continuând cu eBay, Yahoo! si multe alte companii — au pus la dispoziţie 
API-uri specializate. 

Mai mult decât atât, există iniţiative pentru asocierea de descrieri semantice 
serviciilor Web, în contextul direcţiei de evoluţie spre Web-u/ semantic — detalii în 
lucrările lui Sabin Buraga, Tehnologii XML, Polirom, Iasi, 2006 si Sabin Buraga, 
Semantic Web, Matrix Rom, Bucuresti, 2004. 

Printre problemele actuale care trebuie rezolvate numără cele legate de 
neconcordante semantice între servicii la nivel de: 


— continut — de exemplu, un serviciu Web care furnizeaza localizarea unei 
resurse multimedia (¢.g., un film) întoarce adresa numerică (IP) a serverului de 
stocare, deși solicitantul dorește URI-ul acelei resurse; 
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— atribut — se solicită tipul MIME video/mpeg, dar serviciul furnizează tipul 
generic Video; 

— unități de măsură — serviciul solicită ca dată de intrare dimensiunea unui fișier 
audio în octeți, dar i se trimite un număr reprezentând dimensiunea în MB; 

— mesaj — clientul solicitant poate furniza rezoluția unei imagini ca pereche 
latime-inaltime, însă serviciul Web doreşte numărul total de pixeli alocati. 


Pentru descrierea semantică și invocarea corespunzătoare a serviciilor Web, 
eforturile sunt concentrate asupra adoptării unor specificaţii de nivel înalt, 
capabile să descrie proprietăţi și funcţionalităţi într-o formă procesabilă de 
calculator. Astfel, s-a propus un cadru de lucru destinat serviciilor Web descrise 
semantic — SWSF (Semantic Web Services Framework), care înglobează o suită de 
propuneri precum OWL-S și SWSO (Semantic Web Services Ontology). O alta 
inițiativă demnă de interes este WSMO (Web Service Modeling Ontology). 

Conceptual, un serviciu va fi privit ca un proces, căruia — prin proprietăți — 
îi vor fi asociate datele de intrare/ieșire si, eventual, diversi parametri de control. 
Un alt concept important este cel de profil, incluzând meta-date necesare 
descoperirii, selecţiei și potrivirii semantice (matchmaking) de servicii. Modelul de 
procesare vede un serviciu ca fiind atomic ori compus, aspect util în ceea ce 
privește compunerea, execuţia și monitorizarea serviciilor Web. Ultima com- 
ponentă de interes priveşte infrastructura (grounding), desemnând cum poate fi 
executat serviciul și extinzând WSDL. Implementarea efectivă nu are importanță 
în acest context. 

La finalul acestei secțiuni, furnizăm maniera de descriere semantică a unei 
instanţe de serviciu Web de furnizare a cantităţii disponibile dintr-un sortiment 
de portocale (omitem declaraţiile spaţiilor de nume și a modului de specificare 
abstractă a unor resurse): 

<!-- serviciul Web descris --> 

<s:Service ID="FurnizorPortocale"> 

<!-- prezintă un profil --> 


<s:presents 
resource="#profil Furnizor"/» 


<!-- este descris de un proces --> 
<s:describedBy resource="#proces Furnizor"/> 
«1 se bazează pe o descriere-suport ==> 


«s:supports resource-"f£desc Furnizor"/» 
</s:Service> 


<!-- profilul unui serviciu --> 
<p:Profile ID-"profil Furnizor"» 
<s:presentedBy resource="#FurnizorPortocale"/> 


<!-- are asociat un proces --> 
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<p:has_process resource="#proces Furnizor" /> 
<!-- poseda un nume --> 
<p:serviceName>FurnizeazaPortocale</p:serviceName> 
<!-- are o intrare --> 

<p:hasInput resource="#intrare" /> 

<!-- ...si o ieşire (rezultat) --> 


<p:hasOutput resource="#rezultat" /> 
</p:Profile> 


<!-- procesul atomic reprezentând serviciul Web --> 
<a:AtomicProcess ID-"proces Furnizor"» 
<s:describes resource="#FurnizorPortocale" /> 
<!-- descrierea datelor de intrare --> 


<a:hasInput> 
<a:Input ID="intrare"> 


<!-- de la intrare se aşteaptă 

un şir de caractere --> 
<a:parameterType>xsd:string</a:parameterType> 
<!-- semantic, reprezintă o categorie 

de sortiment --> 


<a:semanticType resource-"Sortiment" /> 
</a:Input> 
</a:hasInput> 
<!-- descrierea datelor de iesire --> 
<a:hasOutput> 
<a:Output ID="rezultat"> 


<!-- rezultatul întors va fi un întreg ==> 
<a:parameterType>xsd:integer</a:parameterType> 
<!-- conceptual, reprezinta o cantitate --> 


<a:semanticType resource-"Cantitate" /> 
</a:Output> 
</a:hasOutput> 
</a:AtomicProcess> 


După cum se poate remarca, principalele avantaje aduse de aceste specificații 


conceptuale sunt cele privind automatizarea descoperirii, selectării, invocárii, 


compunerii și monitorizării execuţiei serviciilor Web. 
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p ro | e cta rea Proiectarea siturilor Web. 
siturilor Web Design si functionalitate 


DESIGN ŞI FUNCȚIONALITATE (cartea include CD) (ediţia a II-a) 


EDIȚIA A II-A 


€ STRATEGII DE DESIGN 
SEO (SEARCH ENGINE OPTIMIZATION) 


Lucrarea realizează mai mult decât o introducere în 
domeniul Web, ilustrând potenţialul acestuia de a 
dezvolta aplicaţii puternice din domenii cum ar fi infor- 


marea si documentarea, realitatea virtuală, e-business. 
Cititorul va putea înţelege și exploata posibilităţile oferite 
de noile tehnologii în ceea ce priveşte găsirea de informaţii, 
demararea de afaceri online si proiectarea eficientă a 
siturilor Web. 


POLIROM 


Principalele noutăţi aduse de ediţia a Il-a: Strategii de 
optimizare a siturilor (SEO — Search Engine Optimization) * Utilizabilitatea, ergonomia si 
accesibilitatea siturilor Web ° Securitatea în spaţiul Web * Forumuri, b/og-uri, situri wiki gi 
portaluri * E-branding, e-government, e-learning * Prin XML, spre Web-ul semantic 


Conținutul CD-ului. Studii de caz şi exemple * Documentatii (tutoriale, manuale, specificaţii) in 
limbile română și engleză * Curs de tehnologii Web — 14 prezentări si demonstraţii (în limba 
română) ° Aplicaţii open source pentru comunități virtuale și comerț electronic 
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